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 10:37:32 -0400
From:	Ashwin Chaugule <ashwin.chaugule@...aro.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Mike Turquette <mike.turquette@...aro.org>,
	Morten Rasmussen <morten.rasmussen@....com>,
	Arjan van de Ven <arjan@...ux.intel.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

Hi Peter,

On 15 August 2014 10:07, Peter Zijlstra <peterz@...radead.org> wrote:
> On Fri, Aug 15, 2014 at 09:08:50AM -0400, Ashwin Chaugule wrote:
>> If the OS only looks at Highest, Lowest, Delivered registers and only
>> writes to Desired, then we're not really any different than how we do
>> things today in the CPUFreq layer.
>
> The thing is; we're already struggling to make 'sense' of x86 as it
> stands today. And it looks like this CPPC stuff makes the behaviour even
> less certain.

I think its still better than the "p-state" thing we have going today,
where the algorithms are making their decisions based on the incorrect
assumption that the CPU got what it requested for. (among other things
listed earlier.) CPPC at least gives you a guarantee that the
delivered performance will be within a range you requested. It can
even force the platform to deliver a specific performance value if you
choose over a specific time window.

>
>> Or even in the case of
>> intel_pstate, if you map Desired to PERF_CTL and get value of
>> Delivered by using aperf/mperf ratios (as my experimental driver
>> does), then we can still maintain the existing system performance. It
>> seems like if an OS can make use of the additional information then it
>> should be net win for overall power savings and performance
>> enhancement. Also, using the CPPC descriptors, we should be able to
>> have one driver across X86 and ARM64. (possibly others too.)
>
> Yikes, so aaargh64 will go do creative power management too?

Nice use or aargh. ;) Strangely hadn't seen that before.

>
> And worse; it will go do ACPI? Welcome to the world of guaranteed BIOS
> fail :-(

ACPI or not, I think leads to a rather different kind of debate. :) If
all ARM implementations could include the CP15 equivalents of the CPPC
MSRs that Intel has, then we wouldn't need this CPPC table. But
that'll remain a pipe dream. So I'd prefer to think of CPPC as a
simple wrapper of registers descriptions which allows implementations
to choose how and where to get their CPPC information. However they
choose to implement the registers, I think theres a lot of potential
power savings and performance optimization on the table which can be
acquired through CPPC. Given the platforms some amount of freedom to
optimize things in a platform specific way helps them differentiate
themselves (a key thing with ARM esp.) and keeping the idea of CPU
performance abstract rather than tied to Frequency should help to keep
things unified in the OS, so we avoid the driver bloat that ARM
historically has had.

Cheers,
Ashwin
--
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/