lkml.org 
[lkml]   [2010]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 3/9] perf: export registerred pmus via sysfs

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, 2010-05-10 at 13:27 +0200, Peter Zijlstra wrote:
> > On Mon, 2010-05-10 at 18:26 +0800, Lin Ming wrote:
> >
> > > > No, I'm assuming there is only 1 PMU per CPU. Corey is the expert on
> > > > crazy hardware though, but I think the sanest way is to extend the CPU
> > > > topology if there's more structure to it.
> > >
> > > But our goal is to support multiple pmus, don't we need to assume there
> > > are more than 1 PMU per CPU?
> >
> > No, because as I said, then its ambiguous what pmu you want. If you have
> > that, you need to extend your topology information.
> >
> > Anyway, I talked with Ingo on this and he'd like to see this somewhat
> > extended.
> >
> > Instead of a pmu_id field, which we pass into a new
> > perf_event_attr::pmu_id field, how about creating an event_source sysfs
> > class. Then each class can have an event_source_id and a hierarchy of
> > 'generic' events.
> >
> > 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
> > /...
> >
> >
> > The software events and tracepoints and kprobes stuff we could hang off
> > of /sys/kernel/ or something
>
> The GPU folks would hang is off of the drm class or maybe next to it in
> the PCI space.

It could conceivably be in multiple places as well - a given event makes sense
to enumerate in multiple places.

( For example an 'interrupt' might show up in a given GPU - but it can also
show up amongst the IRQ tracepoints - or something like that. )

But by far the most common case would be for an event source to be attached to
one particular place in the sysfs topology.

Note how naturally this scheme extends to all things hardware topology - which
is already enumerated in sysfs. It also extends to all things software events
in a pretty natural way via /sys/kernel/mm/.

Plus we want to move out the /sys/kernel/debug/ hacks for kprobes and
tracepoints into this space as well. (possibly do it with hw-breakpoints as
well by attaching them to the CPU directory - for completeness)

That way /sys/class/event_source/ would provide an enumeration of all events
to 'perf list' and would automatically be usable by all the perf tooling.

Thanks,

Ingo


\
 
 \ /
  Last update: 2010-05-10 13:51    [W:0.192 / U:5.204 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site