Thread (7 messages) flat view 7 messages, 3 authors, 2018-10-05

Re: [PATCH net-next] udp: Add tracepoints to monitor skbs going in and out of a UDP socket

From: Alexei Starovoitov <hidden>
Date: 2018-10-05 02:03:23
Also in: lkml

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help