[lttng-dev] Tracepoints overhead in x86_64

[g.borello@gmail.com (Gianluca Borello)]

On Aug 31, 2013 1:21 PM, "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>
wrote:
>
> My recommendation would be to implement a dummy trace_sys_enter and
> trace_sys_exit, and then benchmark the overhead of enabling system call
> tracing (this will set TIF_SYSCALL_TRACEPOINT in every thread). So at
> least it would help you pinpoint where most of the overhead comes from.
>

Yes, I already did that before writing the patch I attached in the previous
mail, and I can confirm that simply setting  TIF_SYSCALL_TRACEPOINT in all
threads (without registering any tracepoint) shows the same overhead.

> Indeed, if you come up with ways to shrink the overhead of this "slow
> path", I'm sure the LTTng community would gladly welcome this. Of
> course, these changes would have to be proposed to the Linux kernel
> community. You will need to keep in mind that they will frown upon
> pretty much _any_ slowdown of the fast path (common case, no tracing)
> for improving the speed of the slow (uncommon) case.
>

That might be interesting.
I guess I have a couple of questions:

1) Where do you think I could find an answer to the question "can
trace_sys_enter be safely called from the fast path?". In my tests it
worked just fine, but I'm concerned that calling the tracepoint without
using the IRET slow path could lead to the potential DoS the commit was
fixing.

2) How do you think the kernel community would react to a patch that adds
the tracepoint call to the fast path? Basically, if it works, I'd check the
TIF_SYSCALL_TRACEPOINT directly in the fast path and, if set, I would
proceed in saving the registers and calling the probes, so in the common
case there would be just one more check against the current thread's flags.

Thank you again!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20130831/740f30f1/attachment.html>