Messages in this thread | | | Date | Thu, 10 Dec 2009 13:50:44 -0500 | From | "Frank Ch. Eigler" <> | Subject | Re: [PATCH 2/4] ftrace - add function_duration tracer |
| |
Hi -
On Thu, Dec 10, 2009 at 07:35:08PM +0100, Ingo Molnar wrote: > [...] > target_set.stp is not really adequate. Have you actually _tried_ to use > it on something real like hackbench, which runs thousands (or tens of > thousands) of tasks? You'll soon find that associative arrays are not > really adequate for that ... [...]
A few thousand entries in a hash table is really not that big a deal.
> > > Also, i dont think stap supports proper separation of per workload > > > measurements either. I.e. can you write a script that will work > > > properly even if multiple monitoring tools are running, each trying > > > to measure latencies? > > > > Sure, always has. You can run many scripts concurrently, each with > > its own internal state. (Overheads accumulate, sadly & naturally.) > > To measure latencies you need two probes, a start and a stop one. How do > you define a local variable that is visible to those two probes? You > have to create a global variable - but that will/can clash with other > instances.
You misunderstand systemtap "global" values. They are global to that particular execution of that particular script. They are not shared between scripts that may be concurrently running.
> ( Also, you dont offer per application channels/state from the same > script. Each app has to define their own probes, duplicating the > script and increasing probe chaining overhead. )
Please elaborate what you mean.
> > > Also, i personally find built-in kernel functionality more trustable > > > than dynamically built stap kernel modules that get inserted. > > > > I understand. In the absence of a suitable bytecode engine in the > > kernel, this was the only practical way to do everything we needed. > > You seem to be under the mistaken assumption that your course of action > with SystemTap is somehow limited by what is available (or not) in the > upstream kernel. In reality you can implement anything you want [...]
The message we have received time, after time, after time was stronger: that a suitable interpreter was not going to be welcome in tree. If this is relaxed (and perhaps even if not), we may prototype such a thing in the new year.
- FChE
| |