Overhead of ring buffer in Ftrace
From: Fang Zhou
Date: Fri Aug 02 2019 - 01:42:16 EST
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