Messages in this thread | | | From | Fang Zhou <> | Date | Tue, 6 Aug 2019 12:00:39 -0400 | Subject | Re: Overhead of ring buffer in Ftrace |
| |
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
| |