lkml.org 
[lkml]   [2019]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectOverhead of ring buffer in Ftrace
Hi all,

I’m currently using Ftrace with tracepoints to trace several events in
kernel. But I found the tracing overhead is a little high.

I found the major overhead comes from
“local_dec(&cpu_buffer->committing);” in rb_end_commit() function.
local_dec() will invoke atomic_long_dec(), which finally performs
LOCK_PREFIX plus "DECQ" on this variable.

I'm a little confused. cpu_buffer is a per-cpu buffer. Therefore, I
cannot come up with a scenario that two core runs INC or DEC on the
same per-cpu value at the same time.
So, why do we use such heavy-overhead operation here? Can we just
simply use "DECQ" without LOCK_PREFIX?

Thanks,
Tim

\
 
 \ /
  Last update: 2019-08-02 07:43    [W:0.037 / U:1.788 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site