[lkml]   [2010]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH 3/9] perf: export registerred pmus via sysfs
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2010-05-12 10:15    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean