Messages in this thread | | | Date | Mon, 7 Dec 2009 20:57:48 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 2/2] perf lock: New subcommand "lock" to perf for analyzing lock statistics |
| |
On Mon, Dec 07, 2009 at 08:48:05PM +0100, Frederic Weisbecker wrote: > On Mon, Dec 07, 2009 at 04:38:03PM +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. > > > > Thanks, > > Xiao > > > This profile has been done using ftrace with perf right? > It might be because the lock events are high rate events and > fill a lot of perf buffer space. More than other events. > In one of your previous mails, you showed us the difference > of the size of perf.data by capturing either scheduler events > or lock events.
I'm not sure who sent this email actually. May be you or Hitoshi.
But, anyway you got the point :)
| |