[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D648A65.2040107@dcl.info.waseda.ac.jp>
Date: Wed, 23 Feb 2011 13:17:41 +0900
From: Hitoshi Mitake <mitake@....info.waseda.ac.jp>
To: Frederic Weisbecker <fweisbec@...il.com>
CC: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
linux-kernel@...r.kernel.org, h.mitake@...il.com,
Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] perf lock: clean the options for perf record
On 2011年02月23日 03:22, Frederic Weisbecker wrote:
> On Tue, Feb 22, 2011 at 04:43:35PM +0100, Peter Zijlstra wrote:
>> On Wed, 2011-02-23 at 00:30 +0900, Hitoshi Mitake wrote:
>>> How do you think about it?
>>
>> Most of the lock code (esp the spinlock stuff) is already way over the
>> threshold of sanity, adding to that for some dubious reasons doesn't
>> seem like a good idea.
>>
>> I'm still not at all sure why people want all this lock tracing.
>
> Right, well I can imagine many usecases that could make lock
> tracing bring more value than what lockstat already provides,
> through a tool like perf lock if we enhance it.
>
> We should probably first focus on developing the tooling side
> and make it useful enough that optimizations in the kernel
> side become desirable.
>
Yes, lockstat only provides the lock usage statistics of
entire of the system. perf lock will be able to provide the partial
information of specified term, or the degree of dependency
between locks.
--
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