Re: [PATCH 2/3] introduce intel_rapl driver

[Zhang Rui]

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/