Re: [PATCH 2/4] ftrace - add function_duration tracer

[Ingo Molnar]

* Frank Ch. Eigler <fche@xxxxxxxxxx> wrote:

> 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.

Except if it's a high-freq event and the huge hash table is kept in the 
CPU cache all the time.

> > > > 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.

Ok.

> > ( 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.

Firstly, AFAICS each subsequent systemtap probe for the same event adds 
chaining overhead - and then you have to disambiguate back to the 
originating script. Secondly, is there a way for a single probe to 
multiplex its output to multiple apps? AFAICS that's only possible by 
running multiple scripts.

> > > > 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.

FYI, i suggested this to you 2-3 years ago.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/