This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: BZ#2421 - removing duplicate probe handlers
- From: David Smith <dsmith at redhat dot com>
- To: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, Systemtap List <systemtap at sources dot redhat dot com>
- Date: Thu, 03 Aug 2006 09:21:47 -0500
- Subject: RE: BZ#2421 - removing duplicate probe handlers
- References: <C56DB814FAA30B418C75310AC4BB279D5F45EC@scsmsx413.amr.corp.intel.com>
Josh,
See stuff below.
On Wed, 2006-08-02 at 16:07 -0700, Stone, Joshua I wrote:
> On Wednesday, August 02, 2006 2:14 PM, David Smith wrote:
> > On Tue, 2006-08-01 at 18:49 -0400, Frank Ch. Eigler wrote:
> > The bugzilla references the case we should be optimizing for -
> > something like this:
> >
> > probe kernel.function("sys_read"), kernel.function("sys_write")
> > {
> > log("here")
> > }
> > In addition, I realized that there are cases where we don't want to
> > merge probes even if they are identical (but we could use your idea
> > above of reusing the code bodies). Such as this:
> >
> > probe begin { log("here") }
> > probe begin { log("here") }
> >
> > If we merge those 2 probes into 1, we're only going to get 1 output
> > line instead of 2.
Here's where I confused you. That above "begin" example is wrong. I
believe it actually would work (assuming the code I sent merged
begin/end probes).
> I'm a little worried about how you're merging -- this 'begin' example
> should generate a single probe body which is "triggered" twice at the
> beginning of execution. If that creates only one output, then you're
> breaking semantics.
>
> Consider a similar kprobe case:
>
> probe kernel.function("sys_read"), kernel.function("sys_read")
> {
> log("here")
> }
>
> How many times will this log for each sys_read? The correct answer
> should be two...
>
> Josh
With the code I sent to the list, the above example works correctly (I
changed sys_read to sys_execve to lower the message frequency).
When I speak of merging, here's how it works. With cvs systemtap and
your example, you'd end up with 2 probes at 1 location each (that
happened to be the same location) for a total of 2 locations. With my
changes, the new optimization pass will notice that the 2 probe bodies
are exactly the same, so it will combine the location lists, then delete
the extra probe body. So, we'll end up with 1 probe at 2 locations
(that happen to be the same).
Semantics shouldn't be broken.
--
David Smith
dsmith@redhat.com
Red Hat, Inc.
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)