linux-kernel - Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq

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-next>] [day] [month] [year] [list]

Date:	Wed, 16 Mar 2016 08:47:52 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Michael Turquette <mturquette@...libre.com>
Cc:	rjw@...ysocki.net, linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org, Juri.Lelli@....com,
	steve.muckle@...aro.org, morten.rasmussen@....com,
	dietmar.eggemann@....com, vincent.guittot@...aro.org,
	Michael Turquette <mturquette+renesas@...libre.com>
Subject: Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity

On Tue, Mar 15, 2016 at 03:27:21PM -0700, Michael Turquette wrote:

> That solution scales for the case where architectures have different
> methods. It doesn't scale for the case where cpufreq drivers or platform
> code within the same arch have competing implementations.

Sure it does; no matter what interface we use on x86 to set the DVFS
hints (ACPI, intel_p_state, whatever), using APERF/MPERF is the only
actual way of telling WTH the actual frequency was.

> I'm happy with it as a stop-gap, because it will initially work for
> arm{64} and x86, but we'll still need run-time selection of
> arch_scale_freq_capacity some day. Once we have that, I think that we
> should favor a run-time provided implementation over the arch-provided
> one.

Also, I'm thinking we don't need any of this. Your
cpufreq_scale_freq_capacity() is completely and utterly pointless. Since
its implementation simply provides whatever frequency we selected its
identical to not using frequency invariant load metrics and having
cpufreq use the !inv formula.

See:

  lkml.kernel.org/r/20160309163930.GP6356@...ns.programming.kicks-ass.net

Now, something else (power aware scheduling etc..) might need the freq
invariant stuff, but cpufreq (which we're concerned with here) does not
unless arch_scale_freq_capacity() does something else than simply return
the value we've set earlier.