lkml.org 
[lkml]   [2010]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 0/3] perf: show package power consumption in perf

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

    > 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).

    Btw., some 'perf list' thoughts. We could do a:

    perf list --help rapl:watts

    Which gives the user some idea what an event does. Also, short descriptive
    line in perf list output would be nice:

    $ perf list

    List of pre-defined events (to be used in -e):

    cpu-cycles OR cycles [Hardware event] # CPU cycles
    instructions [Hardware event] # instructions executed

    ...

    rapl:watts [Tracepoint] # watts usage

    or something like that. Perhaps even a TUI for perf list, to browse between
    event types? (in that case it would probably be useful to make them collapse
    along natural grouping)

    We want users/developers to discover new events, see and understand their
    purpose and combine them in not-seen-before ways.

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2010-08-20 14:35    [W:0.027 / U:28.972 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site