lkml.org 
[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
From
Date
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/

\
 
 \ /
  Last update: 2010-05-12 10:15    [from the cache]
©2003-2011 Jasper Spaans