[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1273492164.5605.3397.camel@twins>
Date: Mon, 10 May 2010 13:49:24 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: Lin Ming <ming.m.lin@...el.com>,
Frederic Weisbecker <fweisbec@...il.com>,
"eranian@...il.com" <eranian@...il.com>,
"Gary.Mohr@...l.com" <Gary.Mohr@...l.com>,
Corey Ashford <cjashfor@...ux.vnet.ibm.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>,
Paul Mundt <lethal@...ux-sh.org>,
lkml <linux-kernel@...r.kernel.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Will Deacon <will.deacon@....com>
Subject: Re: [RFC][PATCH 3/9] perf: export registerred pmus via sysfs
On Mon, 2010-05-10 at 13:43 +0200, Ingo Molnar wrote:
>
> Yeah, we really want a mechanism like this in place instead of continuing with
> the somewhat ad-hoc extensions to the event enumeration space.
>
> One detail: i think we want one more level. Instead of:
>
> /sys/devices/system/node/nodeN/node_events
> node_events/event_source_id
> node_events/local_misses
> /local_hits
> /remote_misses
> /remote_hits
> /...
>
> We want the individual events to be a directory, containing the event_id:
>
> /sys/devices/system/node/nodeN/node_events
> node_events/event_source_id
> node_events/local_misses/event_id
> /local_hits/event_id
> /remote_misses/event_id
> /remote_hits/event_id
> /...
>
> The reason is that we want to keep our options open to add more attributes to
> individual events. (In fact extended attributes already exist for certain
> event classes - such as the 'format' info for tracepoints.)
Sure, sounds like a sensible suggestion.
One thing I'd also like to clarify is that !raw events should not be
exhaustive hardware event lists, those are best left for userspace, but
instead are generally useful events that can be expected to be
implemented by any hardware of that particular class.
So a GPU might have things like 'vsync' and 'cmd_pipeline_stall' or
whatever is a generic GPU feature, but not very implementation specific
things that the next generation of hardware won't ever have.
--
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