linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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