linux-kernel - Re: [RFC][PATCH 3/9] perf: export registerred pmus via sysfs

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: <1273653443.5605.3529.camel@twins>
Date:	Wed, 12 May 2010 10:37:23 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Paul Mundt <lethal@...ux-sh.org>
Cc:	Lin Ming <ming.m.lin@...el.com>, Ingo Molnar <mingo@...e.hu>,
	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"eranian@...il.com" <eranian@...il.com>,
	"Gary.Mohr@...l.com" <Gary.Mohr@...l.com>,
	"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Paul Mackerras <paulus@...ba.org>,
	"David S. Miller" <davem@...emloft.net>,
	Russell King <rmk+kernel@....linux.org.uk>,
	lkml <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Will Deacon <will.deacon@....com>,
	Maynard Johnson <mpjohn@...ibm.com>,
	Carl Love <carll@...ibm.com>,
	"greg@...ah.com" <greg@...ah.com>,
	Kay Sievers <kay.sievers@...y.org>
Subject: Re: [RFC][PATCH 3/9] perf: export registerred pmus via sysfs

On Wed, 2010-05-12 at 14:51 +0900, Paul Mundt wrote:
> On Tue, May 11, 2010 at 11:48:42AM +0200, Peter Zijlstra wrote:

> > No all the cpus would have the same event sources. I'm not sure if we
> > can make sysfs understand that though (added GregKH and Kay to CC).
> > 
> This is something I've been thinking about, too. On SH we have a
> large set of perf counter events that are entirely dependent on the
> configuration of the CPU they're on, with no requirement that these
> configurations are identical on all CPUs in an SMP configuration.
> 
> As an example, it's possible to halve the L1 dcache and use that part of
> it as a small and fast memory which has completely different events
> associated with it from the regular L1 dcache events. These events would
> be invalid on a CPU that was running with all cache ways enabled but
> might also be valid on other CPUs that bolt these events to an extra SRAM
> outside of the cache topology completely.
> 
> In any event, the events are at least consistent across all CPUs, it's
> only which ones are valid on a given CPU at a given time that can change.

So you're running with asymmetric SMP systems? I really hadn't
considered that. Will this change at runtime or is it a system boot time
thing?
--
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/