This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC]-Approaches to user space probes ->>> Kprobes and kretprobes
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Thu, 2 Feb 2006 08:05:04 -0500
- Subject: Re: [RFC]-Approaches to user space probes ->>> Kprobes and kretprobes
- References: <44BDAFB888F59F408FAE3CC35AB4704102E87230@orsmsx409>
Hi -
> [...]
> >> [...] In other words we should not see rp->nmissed > 0, however it
> >> is okay to for rp->kp.nmissed > 0.
> >
> >While we may *prefer* not to see any nmissed > 0, how bad do you think
> >the consequences are if we do miss a few? What are the odds?
> Humm.. You are not getting my point. The problem is many times I
> have seen the count of Kprobes_handler_called and count of
> Kretprobes_handler_called for the same function are different. [...]
OK, so you are suggesting that this problem has occurred frequently.
> So if a script assumes that setting some value in Kprobes handler and
> try'ing to unset the same in kretprobe handler might be wrong. [...]
> I am concerned that people might come up with such kind of scripts and
> get wrong results.
That is a problem, but at least those wrong results are not silent.
They will be marked by "missed probes" counts shown at stap shutdown.
> What is the default "maxactive" value set by the systemtap for the
> return probes?
Zero, leaving it to kprobes to set its default. If someone had a
better number to override the resulting value (NR_CPUS?), like a
couple of hundred, they can check in the one-line change to make it
happen.
- FChE