lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ