Messages in this thread | | | Subject | Re: [PATCH 2/2] perf lock: New subcommand "lock" to perf for analyzing lock statistics | From | Steven Rostedt <> | Date | Mon, 07 Dec 2009 11:38:05 -0500 |
| |
On Mon, 2009-12-07 at 16:38 +0800, Xiao Guangrong wrote: > > Ingo Molnar wrote: > > > Also, i agree that the performance aspect is probably the most pressing > > issue. Note that 'perf bench sched messaging' is very locking intense so > > a 10x slowdown is not entirely unexpected - we still ought to optimize > > it all some more. 'perf lock' is an excellent testcase for this in any > > case. > > > > Here are some test results to show the overhead of lockdep trace events: > > select pagefault mmap Memory par Cont_SW > latency latency latency R/W BD latency > > disable ftrace 0 0 0 0 0 > > enable all ftrace -16.65% -109.80% -93.62% 0.14% -6.94% > > enable all ftrace -2.67% 1.08% -3.65% -0.52% -0.68% > except lockdep > > > We also found big overhead when using kernbench and fio, but we haven't > verified whether it's caused by lockdep events.
Well, it is expected that recording all locking is going to have a substantial overhead. In my measurements, a typical event takes around 250ns per event (note, I've gotten this down to 140ns in recent updates, and even 90ns by disabling integrity checks, but I don't want to disable those checks in production).
Anyway, if you add just 100ns to every lock taken in the kernel, that will definitely increase the overhead. Just enable spin_lock() in the function tracer and watch the performance go down. This is why, when using the function tracer I usually add all locking to the notrace filter. This alone helps tremendously in tracing functions.
-- Steve
| |