Messages in this thread |  | | | Subject | Re: [RFC][PATCH 3/9] perf: export registerred pmus via sysfs | | From | Peter Zijlstra <> | | Date | Tue, 11 May 2010 08:46:59 +0200 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |