Re: new static user probe types

[fche at redhat dot com (Frank Ch. Eigler)]

Mark Wielaard <mjw@redhat.com> writes:

> So uprobes is the clear winner for almost zero-overhead when
> disabled.  [...]  But it has the largest overhead when
> enabled. Clearly we want the uprobe mechanism when probes are
> disabled, but the utrace mechanism when probes are enabled! [...]

Yup.

> [...] It would also help with implementing the idea for the ENABLED
> mechanism idea suggested in [PR10013].

Or how about this.  We could expand STAP_PROBE(...) to

   { extern char stap_probe_NNNN_enabled_p;
     if (unlikely(stap_probe_NNN_enabled_p)) {
        /* current inline-asm stuff, but adding
           &enabled_p to the descriptor struct. */
     }
   }

Since this FOO_enabled_p variable would be initialized to 0, this
would allow bypass of all the instrumentation inline-asm in the
instrumentation-off case.  To turn on the instrumentation, the
systemtap runtime would poke at the target process's memory to
(atomically) increment that flag byte, and vice versa.  (Increment
instead of set, in case multiple systemtap sessions are targeting the
same process.)

The inline-asm inside could be the fastest enabled variant, probably
the kprobe-based one.  (This would make user-space sdt.h usable
without utrace & uprobes.)

The explicit ENABLED() test from PR10013 could use the same flag
variable, and thus piggyback on the same run-time mechanism.  (Its
declaration would have to be put into some dtrace-script-generated
header file, I guess.)


- FChE