lkml.org 
[lkml]   [2011]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 2/3] introduce intel_rapl driver
From
Date
On Sat, 2011-05-28 at 03:56 +0800, Peter Zijlstra wrote:
> On Fri, 2011-05-27 at 16:26 +0800, Zhang Rui wrote:
> >
> > > Currently there isn't a way to expose the events in sysfs, but we do
> > > want that, its mostly a matter of getting all involved parties to agree
> > > on a format and implementing it.
> > >
> > I talked with Lin Ming just now, and he said that it should work in this
> > way:
> > First, only one pmu for RAPL interfaces, with four different kinds of
> > events, pkg/core/uncore/dram,
> > and the sysfs I/F is:
> > /sys/bus/event_source/devices/rapl/---|---type
> > |---pkg
> > |---core
> > |---uncore
> > |---dram
>
> Actually something like:
>
> /sys/bus/.../rapl/ -- | -- type
> | -- events -- | -- pkg
> | -- core
> | ...
>
> was one of the latest proposals, but then someone (can't remember who)
> offered the opinion that having sub-groups of event might also be
> wanted.
>
> Furthermore a 'format' file was proposed which ought to contain a
> description of how to compose a ::config value, but we never got around
> to discussing a valid/useful syntax that could express all existing
> cases (let alone be future proof).
>
> > to use it, users can issue something like:
> > perf stat -P rapl -e pkg/core/uncore/dram foo
> > so that event->attr.type equals rapl_pmu.type and event->attr.config
> > equals one of the rapl_domain_id.
>
> Right, something like that, or simply something like -e rapl:pkg, which
> again reminds me that people were working on a full EBNF syntax for the
> -e argument.
>
> > This sounds good. I can rewrite the code to work in this way, but it
> > doesn't work for now, until both sysfs I/F and perf tool being ready,
> > right?
>
> Right, so the only thing missing is the event bits (and some userspace
> bits to use it all). The hardest part of it is getting those definitions
> sorted, writing the patches shouldn't be too hard.
>
Okay. So should I finish the kernel code first, which just checks the
event->attr.type/config value, no matter how they are passed to kernel?

thanks,
rui
>
>




\
 
 \ /
  Last update: 2011-05-30 05:15    [W:0.028 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site