This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: design: function-exit probes
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