Re: [PATCH 2/3] introduce intel_rapl driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux