Re: [PATCH 2/2] perf lock: New subcommand "lock" to perf foranalyzing lock statistics

[Frederic Weisbecker]

On Mon, Dec 07, 2009 at 11:51:23PM +0900, Hitoshi Mitake wrote:
> From: Frederic Weisbecker <fweisbec@xxxxxxxxx>
> > Indeed. I think every lock instance has its own lockdep_map.
> > And this lockdep_map is passed in every lock event but is
> > only used to retrieve the name of the lock.
> > 
> > Why not adding the address of the lockdep_map in the event?
> 
> It's good idea. Address cannot be used as index of array directly,
> but dealing with it is far easier than string and low cost.


Yeah, dealing with lock strings as identifier is like dealing
with the lock class instead of the lock instance. It would
require a very tricky state machine to sort it out.

The address of the lockdep map would be useful as an identifier.
Probably a hashlist based on it would be a good way: we can use
the hashlist from the kernel headers (list.h) in perf tools
already.


 
> > I think that the lock events are much more sensible than the sched events,
> > and that by nature: these are very high frequency events class, probably the
> > highest among every event classes we have (the worst beeing function tracing :)
> > 
> > But still, you're right, there are certainly various things we need to
> > optimize in this area.
> > 
> > More than 8 times slower is high.
> 
> It seems that lockdep contains some O(n) codes.
> Of course lockdep is important, but analyzing statistics of lock usage
> is another problem.
> I think separating lockdep and lock event for stats can be solution.


Indeed.

Thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/