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

[Lin Ming]

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


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