* RE: [RFC]-Approaches to user space probes ->>> Kprobes and kretprobes
@ 2006-02-02 4:24 Keshavamurthy, Anil S
2006-02-02 13:05 ` Frank Ch. Eigler
0 siblings, 1 reply; 2+ messages in thread
From: Keshavamurthy, Anil S @ 2006-02-02 4:24 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: systemtap
>Hi -
>
>anil.s.keshavamurthy wrote:
>
>> [...] I am not an expert in Java or Java probes, but before we lock
>> down this approach I am suggesting that if possible we get feedback
>> from JVM gurus too.
>
>OK, but to involve them at this stage, we have to first formulate the
>issue in a form they can understand. Beyond asking them to add a few
>hooks into their various interpreters (similarly to dtrace), how do
>you think they might be impacted?
All I trying to see is to get more expertise here to look at our current
user probes proposal.
>
>
>> [...] having a counter to count the missed probe does not solve the
>> problem here.
>
>Which problem? That this can occur (with some low probability?)?
>That it may be difficult to detect after occurrence? That it may
>be hard for a user to work around (rerunning may not work)?
>
>> [...] 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. There are chances that Kprobes handler are called but the
corresponding
Kretprobe handler are not called(this could be due to no free kretprobe
instance available).
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. One such
example is Josh's script.
I am concerned that people might come up with such kind of scripts and
get wrong results.
What is the default "maxactive" value set by the systemtap for the
return probes?
-Anil
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [RFC]-Approaches to user space probes ->>> Kprobes and kretprobes
2006-02-02 4:24 [RFC]-Approaches to user space probes ->>> Kprobes and kretprobes Keshavamurthy, Anil S
@ 2006-02-02 13:05 ` Frank Ch. Eigler
0 siblings, 0 replies; 2+ messages in thread
From: Frank Ch. Eigler @ 2006-02-02 13:05 UTC (permalink / raw)
To: Keshavamurthy, Anil S; +Cc: systemtap
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2006-02-02 13:05 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-02-02 4:24 [RFC]-Approaches to user space probes ->>> Kprobes and kretprobes Keshavamurthy, Anil S
2006-02-02 13:05 ` Frank Ch. Eigler
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).