lkml.org 
[lkml]   [2009]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 2/2] perf lock: New subcommand "lock" to perf for analyzing lock statistics
From
From: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Subject: Re: [PATCH 2/2] perf lock: New subcommand "lock" to perf for analyzing lock statistics
Date: Mon, 07 Dec 2009 16:38:03 +0800

Hi Xiao,

>
>
> 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 for your terrible but important data.
Difference between "enable all ftrace" and "enable all ftrace except lockdep"
is significant... This must be reduced.

Thanks
Hitoshi


\
 
 \ /
  Last update: 2009-12-07 16:03    [W:0.070 / U:0.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site