This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: task_finder callback (and engine?) for every uprobe
- From: Jim Keniston <jkenisto at us dot ibm dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: David Smith <dsmith at redhat dot com>, Roland McGrath <roland at redhat dot com>, systemtap at sources dot redhat dot com
- Date: Tue, 16 Dec 2008 11:16:53 -0800
- Subject: Re: task_finder callback (and engine?) for every uprobe
- References: <1229128802.3565.47.camel@dyn9047018139.beaverton.ibm.com> <4947DBD1.5050000@redhat.com> <20081216173155.GC7910@redhat.com>
On Tue, 2008-12-16 at 12:31 -0500, Frank Ch. Eigler wrote:
> Hi -
>
> On Tue, Dec 16, 2008 at 10:48:17AM -0600, David Smith wrote:
> > Jim Keniston wrote:
> > > Investigating PR 7082 & 7092 -- and in particular, instrumenting
> > > task_finder's callbacks -- has reminded me of something we discussed
> > > very briefly earlier: if we have N uprobes in a process, then every time
> > > something happens in that process that requires a task_finder callback,
> > > we get N (calls to) callbacks. E.g., when I probe bash (2170 uprobes),
> > > callbacks happen in blocks of about 2170. Just starting up one instance
> > > of bash yields about 101,900 task_finder callbacks on 2.6.27. [...]
> > [...]
> > (5) uprobe probes on "*" on a specific bash shell
> > # stap -DDEBUG_TASK_FINDER -v -e 'probe process("bash").function("*") {
> > }' -wc bash
> > total attach count: 70070, attach count: 916, inuse count: 1
> > callback count: 139173, vm_callback count: 0
> >
> > Ouch. According to the pass 2 output, there are 2694 probes.
> > [...]
> > So, based on all the above, I don't think this is a task_finder problem,
> > but a stap translator problem. The task_finder can't know when you
> > really need a callback and when you don't, but the translator could
> > figure that out. Jim/Frank, got any different opinions here?
>
> Looking at the stap -p3 output, it does request a separate
> stap_task_finder_target for each uprobe. However, all those requests
> are identical (in terms of callback function pointers and
> pathname/etc.).
>
> The task finder could merge all those requests into one utrace engine
> attachment. Or the translator could put in a corresponding level of
> indirection. Either can be made to work. (The former has the
> advantage of editing C code rather than editing a C code generator,
> and its greater general usefulness.)
>
> - FChE
I don't care much one way or the other. I always thought that the
translator-generated code would need to keep track of processes anyway,
to allocate one set of uprobe objects per process.
Jim