Re: [RFC PATCH 3/3 v3] perf: Update perf tool to monitor uncore events

Lin Ming
2010-12-14T02:10:29Z

On Tue, 2010-12-14 at 09:28 +0800, Corey Ashford wrote:
> On 12/01/2010 09:20 PM, Lin Ming wrote:
> > Uncore events are monitored with raw events with "ru" prefix("u" for uncore).
> > Note that, per-task uncore event is not allowed.
> >
> > $ ./perf stat -e ru0101 -- ls
> > No permission to collect stats.
> > Consider tweaking /proc/sys/kernel/perf_event_paranoid.
> >
> > ./perf stat -a -C 0 -e ru0101 -- ls
>
> Sorry for replying to this thread so late, but I have some concerns
> about this modification.
>
> First of all, "uncore" is an x86-specific term and so it's not clear to
> me if you meant for all arches to utilize this encoding for all "not
> core but on the same die" events (IBM Power arch refers to this as
> "nest" logic).
>
> In the case of the IBM PowerEN chip (aka WireSpeed Processor) we have a
> large number of "uncore" PMUs. It's not clear to me how we should break
> them up using the syntax you've suggested here. Until now, we (IBM)
> have stuck with encoding all PowerEN nest events as PERF_TYPE_RAW and
> utilizing the 64-bit config value to encode which PMU, which event, and
> other necessary event attribute bits.
>
> In one scenario, we could utilize the "u" encoding as suggested in this
> patch, but then we'd be stuck with encoding the specific PMU into the
> config value, really not buying us any convenience.
>
> Another way might be to introduce a bunch of new prefixes for each of
> the PMU's and add corresponding PERF_TYPE_* values. Do we want a bunch
> of arch-specific PERF_TYPE_* values in include/linux/perf_event.h?
> Having that many PMUs, we might want a more sophisticated prefix scheme,
> perhaps something like what Stephane Eranian uses in libpfm4:
> <pmu>::nnnn, e.g:
>
> perf stat -C 0 -e runc::0101
> or more verbosely,
> perf stat -C 0 -e runcore::0101
>
> For the PowerEN chip, we have PMUs for these nest functional units:
> XML accelerator
> Regular expression accelerator
> Crypto accelerator
> PowerBus interface chiplet (0..3)
> Network accelerator
> Memory controller Synchronous (0..1)
> Memory controller Asynchronous (0..1)
> etc.
>
> I can see value in adding something like:
>
> perf stat -C 0 -e rmcs0::1d
>
> On the other hand, I don't want to get carried away with this, when we
> have the sysfs solution coming down the road, which I think will reduce
> or eliminate the need for these prefixes.
>
> Is PERF_TYPE_UNCORE and the "u" encoding intended to be a temporary
> solution? How do you envision someone using sysfs to specify an uncore
> event (especially one with a raw encoding)?

Yes, they are temporary solution. I use it to easily test uncore
patches. Sorry I should mention that.

sysfs is the final solution, but I'm not clear how the sysfs structures
should be.

As we discussed before,

1. Should we list all events under sysfs?

/sys/devices/system/cpu/cpuN/events/event0
...
/sys/devices/system/cpu/cpuN/events/eventN

/sys/devices/system/node/nodeN/pmuN/events/event0
...
/sys/devices/system/node/nodeN/pmuN/events/eventN

2. Or should we use a sysfs file to pass in raw config value?

/sys/devices/system/cpu/cpuN/raw
/sys/devices/system/node/nodeN/pmuN/raw?

3. How will the additional attributes(needed by IBM PowerEN chip, etc)
be passed in?

4. and other problems I don't remember now.

>
> - Corey