Re: design: function-exit probes

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Tue, 2005-02-15 at 02:23, Maneesh Soni wrote:
> On Mon, Feb 14, 2005 at 09:01:38AM -0800, Jim Keniston wrote:
> [..]
> > maxactive is specified by the user.  It is the number of instances of the
> > probed function that can be active concurrently.  For example, if the
> > function is non-recusrive and is called with a spinlock or mutex held,
> > maxactive = 1 should be enough.  If the function never sleeps and is
> > not recursive, NR_CPUS should be enough. (Right?)  maxactive is used to
> 
> If I am not wrong, here we should keep kernel premption also in mind. So,
> in addition to above conditions, maxactive will be NR_CPUS when premption
> is disabled.

Good point.  So it's better to say that the user can count on NR_CPUS
being enough only if the function is not recursive and cannot relinquish
the CPU -- e.g., via a semaphore or preemption.

Anybody know enough about the "typical" behavior of systems built with
CONFIG_PREEMPT to suggest an appropriate default value for maxactive in
this case?  If not, I'd propose something like max(2*NR_CPUS, 10), and
count on the user to specify a better value if s/he knows one.

> 
> > 
> > 1.5	Assumptions and Limitations
> > 
> > 1.  This requires a probepoint (but not necessarily a user-defined
> > handler) at the entry to every function whose returns are traced.
> 
> I think we need to take care for the case when user explicitly
> wants to probe function entry point. I am not sure if kprobe
> handles two probe handler for the same address.

I don't think I understand your concern.  Kprobes already allows you to
probe entry points. As it's currently specified, the only way to
register a function-return probe is as a companion to a function-entry
probe.  But it shouldn't be too hard to allow entry and return probes to
be registered and deregistered independently, if people want to do that.

> 
> 
> Thanks
> Maneesh

Jim