On Fri, Oct 05, 2018 at 12:24:42AM +0100, David Howells wrote:
As for kprobes: spots, plural. Using kprobes involves installing breakpoint
instructions and taking traps and would seem to require using printk for the
output, which would affect the timings and potentially affect the situation,
especially given the sheer amount of traces produced. Note that one of these
was in an interrupt handler, which is possibly not the best place to be taking
an illegal instruction trap.
Using kprobes gets worse too. In my case, the source code and the build tree
aren't on the test machine, which I understand would be a requirement - and
there is quite a bit of misunderstanding in the above two paragraphs about kprobes.
Sounds like it influences odd design choices with tracepoints.
- kprobes at the top of the function don't use traps and they've been
optimized over the years to have very low overhead
- trace_printk is using the same mechanism as tracepoint prints
- both trace_printk and tracepoints can affect timing
- kprobes and trace_printk work well out of irq handler. They work out of NMI too
- build tree doesn't need to be present to use kprobes
perf, bcc and others tools have user friendly (arguable of course) interfaces
for kprobes.