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

[Will Deacon]

Hi Peter,

Thanks for CC'ing me on this.

On Mon, 2010-05-10 at 12:42 +0100, Peter Zijlstra wrote:
> (Added Will Deacon)
> 

<snip>


> > We'd start using the PERF_TYPE_ space for this and express the
> > PERF_COUNT_ space in the event attributes found inside that class.
> >
> > That way we can include all the existing event enumerations into this as
> > well.
> >
> > This way we can create:
> >
> > /sys/devices/system/cpu/cpuN/cpu_hardware_events
> >                              cpu_hardware_events/event_source_id
> >                              cpu_hardware_events/cpu_cycles
> >                              cpu_hardware_events/instructions
> >                                                 /...
> >
> > /sys/devices/system/cpu/cpuN/cpu_raw_events
> >                              cpu_raw_events/event_source_id
> >
> >
> > These would match the current PERF_TYPE_* values for compatibility
> >
> > For new PMUs we can start a dynamic range of PERF_TYPE_ (say at 64k but
> > that's not ABI and can be changed at any time, we've got u32 to play
> > with).
> >
> > For uncore this would result in:
> >
> > /sys/devices/system/node/nodeN/node_raw_events
> >                                node_raw_events/event_source_id
> >
> > and maybe:
> >
> > /sys/devices/system/node/nodeN/node_events
> >                                node_events/event_source_id
> >                                node_events/local_misses
> >                                           /local_hits
> >                                           /remote_misses
> >                                           /remote_hits
> >                                           /...
> >


I like this approach, but it only makes sense for ARM if we describe the
common subset of events [that is, those associated with a PERF_COUNT_]
because, although the ARMv7 architecture does define some common event
numberings between cores, implementors are at liberty to extend the
event space as they wish. These extensions are much better off being
handled in userspace.

Another interesting ARM-ism is the vast potential for uncore event
sources in SoC devices. The `node' terminology seems a bit confusing
here, as there may be counters situated at various points of a bus
hierarchy which monitor various types of transactions for example. I
suppose these could live under /sys/devices/system/bus/... ? I would
expect these kind of counters to be controlled via raw events because
having a list of discrete events doesn't really make sense [for example,
if I want to count all bursts of a given size, I can encode the burst
size into the event number].


> So Russell reminded me that the ARM people have the problem that
> their /proc/cpuinfo isn't specific enough to map to a unique event map.

> Whilst extending ARM /proc/cpuinfo seems like a sensible option it will
> not cover anything but cpu events.
> 
> So in that trend (and to avoid exhaustive in kernel event lists for no
> good reason), it might make sense to also add some event_source
> attributes that identify the thing, maybe a event_source_name or
> event_source_driver field that would allow unique maps to exhaustive
> event lists.


The ARM perf events backend already has an ID field in the pmu struct
which can be used to lookup a string describing what the event source
is. Exporting this via sysfs will make it much easier for userspace [and
is basically how OProfile deals with PMU identification].

Cheers,

Will


--
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/