On Mon, 2010-05-10 at 13:43 +0200, Ingo Molnar wrote:
quoted text
> 
> 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.


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