This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Dynamic djprobe (and summary of Q&A)


karim wrote:

> [...]  Here I have a mechanism that claims that sometimes it can be
> very fast and sometimes if can very costly. [...]

(For varying values of "very".)

> Yet, I'm usually doing one of two things:

> a) Either I'm just shooting in the dark trying to find a problem, in which
> case krpobes is god-sent.
> b) Either I'm interested to know exactly how much time it takes for some
> piece of code to traverse various paths, in which case I'd want _all_ the
> probe points I insert to cost virtually nothing.

I wonder if the "_all_" is not quite as important as that.  For
someone so strictly inclined, the translator could be made to assert
djprobe availability for all spots, and know what to do with an
"unable" error.  For someone else who's not so absolutist, it may be
enough to know which probes ended up using which breakpoint mechanism.
We may be able to measure the overheads to allow factoring out of the
differences.

There does not seem to be a resource constraint in concurrently
inserted djprobes, so switching dynamically, such as on the grounds of
frequent invocation, is probably not helpful.  Similarly, the djprobes
applicability predicates don't seem random, so results would be
reproducible from run to run.


> [...] Because in reality [...] it will come down to:
> - If you need ad-hoc, non-performance-critical probe points use kprobes
>   or the krpobes/djprobes mix.
> - If you need performance-critical probe points, use static probes
>   (which may be the "markers" thing or something entirely different.)

I suspect such a black & white dichotomy does not apply widely.  But
even if it does, it is not relevant to properties of the Hitachi
djprobes code.  Once one is willing to put markers into the kernel
source and recompile and reboot, then one doesn't even have to use
djprobes per se to go fast (much faster than int3).


- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]