[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100512055112.GA4691@linux-sh.org>
Date: Wed, 12 May 2010 14:51:12 +0900
From: Paul Mundt <lethal@...ux-sh.org>
To: Peter Zijlstra <peterz@...radead.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 Tue, May 11, 2010 at 11:48:42AM +0200, Peter Zijlstra wrote:
> On Tue, 2010-05-11 at 17:40 +0800, Lin Ming wrote:
> > Is /sys/class/event_sources/* looks like,
> >
> > /sys/class/event_sources/cpu_hw_events0
> > -> /sys/devices/system/cpu/cpu0/cpu_hw_events
> > ...
> > /sys/class/event_sources/cpu_hw_eventsN
> > -> /sys/devices/system/cpu/cpuN/cpu_hw_events
> >
> > /sys/class/event_sources/cpu_hw_cache_events0
> > -> /sys/devices/system/cpu/cpu0/cpu_hw_events
> > ...
> > /sys/class/event_sources/cpu_hw_cache_eventsN
> > -> /sys/devices/system/cpu/cpuN/cpu_hw_events
>
> Hmm, good question.
>
> 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.
--
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