linux-kernel - Re: [PATCH 2/2] perf lock: New subcommand "lock" to perf for analyzing lock statistics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091207201652.GD5049@nowhere>
Date:	Mon, 7 Dec 2009 21:16:55 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Hitoshi Mitake <mitake@....info.waseda.ac.jp>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org,
	a.p.zijlstra@...llo.nl, paulus@...ba.org, tzanussi@...il.com,
	srostedt@...hat.com
Subject: Re: [PATCH 2/2] perf lock: New subcommand "lock" to perf for
	analyzing lock statistics

On Mon, Dec 07, 2009 at 11:51:23PM +0900, Hitoshi Mitake wrote:
> From: Frederic Weisbecker <fweisbec@...il.com>
> > 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/