Re: MARKER mechanism, try 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Ingo Molnar ([email protected]) wrote:
> 
> * Mathieu Desnoyers <[email protected]> wrote:
> 
> > It supports 5 modes :
> > 
> > - marker becomes nothing
> > - marker calls printk
> > - marker calls a tracer
> > - marker puts a symbol (for kprobe)
> > - marker puts a symbol and 5 NOPS for a jump probe.
> 
> just go for 'nothing' and the 5-NOP variant, and please implement 
> support for it from within LTT, via a kprobe - if you want me to support 
> this stuff for upstream inclusion. If we support any static tracer mode 
> and LTT does not support the kprobe mode then we are back to square 1 
> wrt. dependencies ...
> 

I am open to make LTTng support kprobes as a commodity (in fact, this point has
been on the LTTng project roadmap for almost a year). But in no way does it
solve the entire tracing problem. As an example, LTTng traces the page fault
handler, when kprobes just can't instrument it.

I keep thinking that a complete marker mechanism must have the ability to be
turned into function calls or inline functions when necessary.

Going further, we could think of a marker mechanism that would be aware of the
"difficulty" level of the probe, so that even if CONFIG_KPROBELOG is selected,
it would use a direct call or inlined function for probing the page fault
handler.

i.e. :

"normal" (nothing, kprobe, jumpprobe, printk or tracer)
MARK(eventname, "%d %s", myint, mystring);

"cannot be probed dynamically" (used in kprobes itself, page fault handler)
                               (only nothing or tracer)
MARK_NOPROBE(eventname, "%d %s", myint, mystring);

"cannot use printk" (used in scheduler, NMIs, wakeup, printk itself)
                    (nothing, kprobe, jumpprobe or tracer)
MARK_NOPRINT(eventname, "%d %s", myint, mystring);

Using the following table to select the mechanism :

Config/probe declaration     |   normal      |    noprobe    |     noprint
------------------------------------------------------------------------------
nothing                      |   nothing      |   nothing     |    nothing
kprobe                       |   kprobe       |   tracer      |    kprobe
jumpprobe                    |   jumpprobe    |   tracer      |    jumpprobe
printk                       |   printk       |   tracer      |    kprobe
tracer                       |   tracer       |   tracer      |    tracer

Therefore, selecting the "kprobe" configuration option would still let people
instrument the hardest paths while having mostly dynamic probes.

Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux