[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1311271328590.22932@pianoman.cluster.toy>
Date: Wed, 27 Nov 2013 13:35:35 -0500 (EST)
From: Vince Weaver <vince@...ter.net>
To: Stephane Eranian <eranian@...gle.com>
cc: linux-kernel@...r.kernel.org, peterz@...radead.org, mingo@...e.hu,
ak@...ux.intel.com, acme@...hat.com, jolsa@...hat.com,
zheng.z.yan@...el.com, bp@...en8.de, maria.n.dimakopoulou@...il.com
Subject: Re: [PATCH v7 3/4] perf,x86: add Intel RAPL PMU support
On Tue, 12 Nov 2013, Stephane Eranian wrote:
> This patch adds a new uncore PMU to expose the Intel
> RAPL energy consumption counters. Up to 3 counters,
> each counting a particular RAPL event are exposed.
>
> The RAPL counters are available on Intel SandyBridge,
> IvyBridge, Haswell. The server skus add a 3rd counter.
So I notice PP1 (which is the GPU power on non-server chips)
is not supported.
Is that just for simplicity?
> The following events are available and exposed in sysfs:
> - power/energy-cores: power consumption of all cores on socket
> - power/energy-pkg: power consumption of all cores + LLc cache
> - power/energy-dram: power consumption of DRAM (servers only)
This "power" naming seems a bit generic. If other hardware has power
measurements can they be put in the same directory?
power/gpu? power/usb?
Also, can support for reading the power from other vendors be put here?
Like AMDs (unfortunately named) APM (active power management) power
readings?
> Files are:
> /sys/devices/power/events/energy-*.unit
> /sys/devices/power/events/energy-*.scale
Are all of these sys files having documentation added under
Documentation/ABI?
> The RAPL PMU is uncore by nature and is implemented such
> that it only works in system-wide mode. Measuring only
> one CPU per socket is sufficient. The /sys/devices/power/cpumask
> file can be used by tools to figure out which CPUs to monitor
> by default. For instance, on a 2-socket system, 2 CPUs
> (one on each socket) will be shown.
do the measurements require CAP_SYS_ADMIN like other system-wide uncore
measurements? It didn't look like it in the patch but I might have missed
it.
I'm sure the security people will start making claims that you can make
guesses about password encryption algorithms based on the global power
consumption numbers.
Sorry if these are annoying questions, I am glad to see this driver make
progress, as I've had the misfortune of maintaining various user-space-MSR
hacks designed to get this info because of lack of kernel support.
Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists