RE: BZ#2421 - removing duplicate probe handlers

[David Smith <dsmith at redhat dot 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)