From: Ingo Molnar <mingo@elte.hu>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Zhang Rui <rui.zhang@intel.com>,
"Lin, Ming M" <ming.m.lin@intel.com>,
Matt Fleming <matt@console-pimps.org>,
LKML <linux-kernel@vger.kernel.org>,
"robert.richter@amd.com" <robert.richter@amd.com>,
"acme@redhat.com" <acme@redhat.com>,
"paulus@samba.org" <paulus@samba.org>,
"dzickus@redhat.com" <dzickus@redhat.com>,
"gorcunov@gmail.com" <gorcunov@gmail.com>,
"fweisbec@gmail.com" <fweisbec@gmail.com>,
"Brown, Len" <lenb@kernel.org>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC PATCH 0/3] perf: show package power consumption in perf
Date: Fri, 20 Aug 2010 14:31:59 +0200 [thread overview]
Message-ID: <20100820123159.GA3321@elte.hu> (raw)
In-Reply-To: <1282296855.2605.724.camel@laptop>
* 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
next prev parent reply other threads:[~2010-08-20 12:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-18 7:59 [RFC PATCH 0/3] perf: show package power consumption in perf Zhang Rui
2010-08-18 12:25 ` Peter Zijlstra
2010-08-18 12:41 ` Matt Fleming
2010-08-19 3:28 ` Lin Ming
2010-08-19 7:54 ` Matt Fleming
2010-08-19 8:15 ` Lin Ming
2010-08-19 8:31 ` Zhang Rui
2010-08-19 8:32 ` Matt Fleming
2010-08-19 9:44 ` Peter Zijlstra
2010-08-21 1:18 ` Frederic Weisbecker
2010-08-21 9:30 ` Ingo Molnar
2010-08-23 9:31 ` Peter Zijlstra
2010-08-19 9:02 ` Peter Zijlstra
2010-08-20 1:44 ` Zhang Rui
2010-08-20 9:34 ` Peter Zijlstra
2010-08-20 12:31 ` Ingo Molnar [this message]
2010-08-20 21:34 ` acme
2010-08-19 2:43 ` Lin Ming
2010-08-19 8:54 ` Peter Zijlstra
2010-08-20 0:21 ` Lin Ming
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100820123159.GA3321@elte.hu \
--to=mingo@elte.hu \
--cc=acme@redhat.com \
--cc=dzickus@redhat.com \
--cc=fweisbec@gmail.com \
--cc=gorcunov@gmail.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@console-pimps.org \
--cc=ming.m.lin@intel.com \
--cc=mjg59@srcf.ucam.org \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=robert.richter@amd.com \
--cc=rostedt@goodmis.org \
--cc=rui.zhang@intel.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).