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

<p dir="ltr">> Indeed, if you come up with ways to shrink the overhead of this "slow<br>
> path", I'm sure the LTTng community would gladly welcome this. Of<br>
> course, these changes would have to be proposed to the Linux kernel<br>
> community. You will need to keep in mind that they will frown upon<br>
> pretty much _any_ slowdown of the fast path (common case, no tracing)<br>
> for improving the speed of the slow (uncommon) case.<br>
></p>
<p dir="ltr">That might be interesting.<br>
I guess I have a couple of questions:</p>
<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">Thank you again!</p>