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

[Karim Yaghmour <karim at opersys dot com>]

Frank Ch. Eigler wrote:
> But there does not have to be a message.  Depending on when the
> failure of the applicability predicates becomes known (translation or
> insertion time), the djprobe can be downgraded to a plain kprobe.

Ah, yes, I was expecting that one ... didn't expect it'd that fast though :)

Let me take a users' perspective for a moment here:

Here I have a mechanism that claims that sometimes it can be very fast and
sometimes if can very costly. Since this is a tool that is supposed to be
useful for those uninterested in dissassembling kernel code to find
locations to for krpobes, I'm not expected to go around finding where it'll
be fast and where it won't. 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.

Yet, what's being suggested (a mixed combination of kprobes/djprobes)
is something that I'll only be able to use for "a", never for "b" given
that kprobes will be a transparent fallback. IOW, if I need "b", I
can't rely on the mixed-approach, and there's no other route than static
probe points.

---

And therein lies the rub. Promoting this as anything else but a sometimes-
faster-probe-than-kprobes is going to be misleading. And it will actually
be of little practical advantage because it will only be a candidate for
those very same cases where kprobes was already a candidate: non-
performance-critical paths. And when someone is considering performance,
he's always going to keep in mind what will happen in the slowest path.

Given how people use such tools, I ask :
- How useful is this mechanism really?
- Is user confusion over where and when they will see the advantages of
  this mechanism worth it?

Because in reality, once the confusion is cleared, 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.)

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546