Re: [RFC PATCH 0/3] perf: show package power consumption in perf

[Peter Zijlstra <peterz@infradead.org>]

On Fri, 2010-08-20 at 09:44 +0800, Zhang Rui wrote:
> On Thu, 2010-08-19 at 17:02 +0800, Peter Zijlstra wrote:

> > its some obscure perf feature:
> > 
> >  leader = sys_perf_event_open(&hrtimer_attr, pid, cpu, 0, 0);
> >  sibling = sys_perf_event_open(&rapl_attr, pid, cpu, leader, 0);
> > 
> > will create an even group (which means that both events require to be
> > co-scheduled). If you then provided:
> > 
> > hrtimer_attr.read_format |= PERF_FORMAT_GROUP;
> > hrtimer_attr.sample_type |= PERF_SAMPLE_READ;
> > 
> hrtimer_attr is only shared in an event group, and rapl needs its owen
> event group, right?

Uhm, no. The idea is to group the hrtimer and rapl event in order to
obtain rapl 'samples'.

That is, you get hrtimer samples which include the rapl count. For this
we use the grouping construct where group siblings are always
co-scheduled and can report on each others count.

> so what do you think the rapl counter should look like in userspace?
> showing it in perf-stat looks nice, right? :)

Right, so the userspace interface would be using Lin's sysfs bits, which
I still need to read up on. But the general idea is that each PMU gets a
sysfs representation somewhere in the system topology reflecting its
actual site (RAPL would be CPU local), this sysfs representation would
then also allow you to discover all events it provides.

perf list will then use sysfs to discover all available events, and you
can still use perf stat -e $foo to select it, where foo is some to be
determined string that identifies the thing, maybe something like:
rapl:watts or somesuch (with rapl identifying the pmu and watts the
actual event for that pmu).