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

* Frank Ch. Eigler <fche@redhat.com> 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


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