lkml.org 
[lkml]   [2009]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/4] ftrace - add function_duration tracer
Hi -

On Thu, Dec 10, 2009 at 09:14:54PM +0100, Ingo Molnar wrote:
> [...]
> > 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.

OK. (For reference, an int->int hash table slot costs about 40 bytes,
so an L2 cache could carry quite a few of them.)


> Firstly, AFAICS each subsequent systemtap probe for the same event
> adds chaining overhead - and then you have to disambiguate back to
> the originating script.

Right, but at some point this kind of demultiplexing has to occur
somewhere along the line. In practice, chaining a la kprobes or
tracepoints is negligible compared to the other costs.


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

As in having multiple files to write to? There's no easy & direct way
to do that right now (beyond unmerged per-cpu files in "bulk" mode).
One can have systemtap print data on multiple synthetic /proc/.../
files, but that has other tradeoffs. Or one could demultiplex in user
space (for example by prefixing text lines, or using binary records).


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

OK, well, I hope that when the time comes, the messages will be less
mixed than usual. :)


- FChE


\
 
 \ /
  Last update: 2009-12-10 22:33    [W:0.042 / U:1.832 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site