[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130730085256.GK3008@twins.programming.kicks-ass.net>
Date: Tue, 30 Jul 2013 10:52:56 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Konstantin Krivyakin <k.krivyakin@...sung.com>
Cc: linux-kernel@...r.kernel.org, rjw@...k.pl, viresh.kumar@...aro.org,
mingo@...hat.com, kgene.kim@...sung.com, linux-pm@...r.kernel.org,
i.zhbanov@...sung.com, e.voevodin@...sung.com,
kyungmin.park@...sung.com, akpm@...ux-foundation.org
Subject: Re: [PATCH RFC 0/3] Per-process power consumption measurement
facility
On Tue, Jul 30, 2013 at 12:17:36PM +0400, Konstantin Krivyakin wrote:
> This patchset adds per-process power consumption measurement facility.
> Power consumption is very important on mobile platforms. This code
> allows to measure consumed power in Watts*Hours. The consumed power
> for process is updated on scheduler switch and depends on current
> CPU voltage and frequency.
>
> The formula for computation is: P = C * V^2 * f, where C is a constant
> that reflects capacity of the system, V is the current voltage and
> f is the current frequency.
> (Taken from: http://en.wikipedia.org/wiki/CPU_power_dissipation).
>
> In this patchset was added implementation for Exynos platform
> to demonstrate how it works.
>
> To minimize scheduler impact for each CPU P-state the value of (V^2 *f)
> was precomputed at the time of platform initialization.
It seems to me the 3 multiplies that takes could be done when cpufreq
actually changes the P-state.
> And to reduce performance impact furthermore, the C constant is multiplied
> in userspace.
That seems particularly silly; how is userspace to know C and why
isn't it a much better idea to do this in the code generating the number
for userspace to consume.
Also, I intensely dislike this thing because:
- it adds more user interface
- it adds more accounting muck
- it completely lacks any useful changelogs
- it completely fails to even begin addressing the issues we already
have with cpufreq
There's been a lot of talk about power aware scheduling in the recent
past, there's also been a lot of problems listed we must overcome/solve.
This patch set completely fails to tie into any of that.
You also completely fail to explain the user case and thus related why
you can't use any of the other facilities like perf or ftrace to measure
this.
--
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