Overhead of ring buffer in Ftrace

Overhead of ring buffer in Ftrace

[Fang Zhou]

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

Re: Overhead of ring buffer in Ftrace

[Fang Zhou]

Any ideas or suggestions?

Best,
Tim

On Fri, Aug 2, 2019 at 1:41 AM Fang Zhou <timchou.hit@gmail.com> wrote:
>
> 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