Messages in this thread | | | Subject | Re: [RFC PATCH 0/3] perf: show package power consumption in perf | From | Peter Zijlstra <> | Date | Fri, 20 Aug 2010 11:34:15 +0200 |
| |
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).
| |