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

[Peter Zijlstra]

On Mon, 2010-05-10 at 16:13 -0700, Corey Ashford wrote:

> Having extra fields for each event would allow us to describe hardware-specific event attributes.  For example:
> /sys/devices/system/node/nodeN/node_events
>                                node_events/event_source_id
>                                node_events/local_misses/event_id
>                                           /local_hits/event_id
>                                           /crypto_datamover  <- specific node PMU
>                                               /marked_crb_rcv_des
>                                                   /event_id
>                                                   /attrib
>                                                          /lpid <- attribute name
>                                                          /lpid/type <- type of attribute (boolean, integer, etc.)
>                                                          /lpid/min  <- min value of int attribute
>                                                          /lpid/max  <- max value of int attribute
>                                                          /lpid/bit_offset <- amount to shift attribute value before OR'ing into the raw event code
>                                                          /marking_mode <- attribute name
>                                                          /marking_mode/type
>                                                          /...
> 
> Of course, these nodes would need to be replicated for each event that needs them or other attributes.

I would suggest having a 1:n pmu:event_source ratio, not the other way
around. So in your example above the crypto_datamover PMU thingy would
get its own event_source(s), which get placed at whatever place in the
machine topology they live. If that happens to be at the node level,
place them there.

> >> 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.
> 
> Why exactly is this?  I got the impression this was something you and
> Ingo wanted earlier.  As big of an impact as it will be, it would be
> nice to unify the two event spaces (generic and raw) into one space
> that can be explored by a user space tool (or even crudely
> by /bin/ls).

No we want generic event spaces that have events that are generally
applicable to a whole class of PMUs, so say to all CPU PMUs, or all GPU
PMUs or all PCI-bridge PMUs.

What we do not want are exhaustive event lists for specific PMU
implementations, those are best left for userspace.

I'll let Ingo answer your other question.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/