[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20091208.000048.123217523.mitake@dcl.info.waseda.ac.jp>
Date: Tue, 08 Dec 2009 00:00:48 +0900 (JST)
From: Hitoshi Mitake <mitake@....info.waseda.ac.jp>
To: xiaoguangrong@...fujitsu.com
Cc: mingo@...e.hu, fweisbec@...il.com, linux-kernel@...r.kernel.org,
a.p.zijlstra@...llo.nl, paulus@...ba.org, tzanussi@...il.com,
srostedt@...hat.com, kosaki.motohiro@...fujitsu.com
Subject: Re: [PATCH 2/2] perf lock: New subcommand "lock" to perf for
analyzing lock statistics
From: Xiao Guangrong <xiaoguangrong@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists