linux-kernel - Re: [RFC 0/3] Experimental patchset for CPPC

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:	Fri, 15 Aug 2014 08:47:54 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Ashwin Chaugule <ashwin.chaugule@...aro.org>
CC:	Peter Zijlstra <peterz@...radead.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Mike Turquette <mike.turquette@...aro.org>,
	Morten Rasmussen <morten.rasmussen@....com>, mingo@...nel.org,
	len.brown@...el.com, rjw@...ysocki.net,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
	Arnd Bergmann <arnd@...db.de>, linux-acpi@...r.kernel.org,
	cpufreq@...r.kernel.org, Patch Tracking <patches@...aro.org>,
	Dirk Brandewie <dirk.brandewie@...il.com>
Subject: Re: [RFC 0/3] Experimental patchset for CPPC

On 8/15/2014 7:24 AM, Ashwin Chaugule wrote:
>>>
>>> we've found that so far that there are two reasonable options
>>> 1) Let the OS device (old style)
>>> 2) Let the hardware decide (new style)
>>>
>>> 2) is there in practice today in the turbo range (which is increasingly
>>> the whole thing)
>>> and the hardware can make decisions about power budgetting on a timescale
>>> the OS
>>> can never even dream of, so once you give control the the hardware (with
>>> CPPC or native)
>>> it's normally better to just get out of the way as OS.
>>>
>>
>
> Interesting. This sounds like X86 plans to use the Autonomous bits
> that got added to the CPPC spec. (v5.1)?

if and when x86/Intel implement that, we will certainly evaluate it to see
how it behaves... but based on todays use of the hw control of the actual
p-state... I would expect that evaluation to pass.

note that on todays multi-core x96 systems, in practice you operate mostly
in the turbo range (I am ignoring mostly-idle workloads since there the
p-state isn't nearly as relevant anyway); all it takes for one of the cores to request
a turbo-range state, and the whole chip operates in turbo mode.. and in turbo mode
the hardware already picks the frequency/voltage.

with the current (and more so, past) Linux behavior, even at moderate loads you end up
there; the more cores you have the more true that becomes.

> I agree that the platform can
> make decisions on a much finer timescale. But even in the
> non-Autonomous mode, by providing the bounds around a Desired Value,
> the OS can get out of the way knowing that the platform would deliver
> something in the range it requested. If the OS can provide bounds, it
> seems to me that the platform can make more optimum decisions, rather
> than trying to guess whats running (or not).

I highly question that the OS can provide intelligent bounds.

When are you going to request an upper bound that is lower than maximum?
(don't say thermals, there are other mechanisms for controlling thermals
that work much better than direct P state control). Are you still going to do that
even if sometimes lower frequencies end up costing more battery?
(race-to-halt and all that)

I can see cases where you bump the minimum for QoS reasons, but even there I would
dare to say that at best the OS will be doing wild-ass guesses.

--
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/