Messages in this thread | | | Date | Thu, 4 Oct 2018 19:03:18 -0700 | From | Alexei Starovoitov <> | Subject | Re: [PATCH net-next] udp: Add tracepoints to monitor skbs going in and out of a UDP socket |
| |
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.
| |