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]

Message-ID: <20140815061917.GX19379@twins.programming.kicks-ass.net>
Date:	Fri, 15 Aug 2014 08:19:17 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Ashwin Chaugule <ashwin.chaugule@...aro.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@...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@...il.com
Subject: Re: [RFC 0/3] Experimental patchset for CPPC

On Thu, Aug 14, 2014 at 05:56:10PM -0400, Ashwin Chaugule wrote:
> Hi Peter,
> 
> On 14 August 2014 16:51, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Thu, Aug 14, 2014 at 03:57:07PM -0400, Ashwin Chaugule wrote:
> >>
> >>
> >> What is CPPC:
> >> =============
> >>
> >> CPPC is the new interface for CPU performance control between the OS and the
> >> platform defined in ACPI 5.0+. The interface is built on an abstract
> >> representation of CPU performance rather than raw frequency.  Basic operation
> >> consists of:
> >
> > Why do we want this? Typically we've ignored ACPI and gone straight to
> > MSR access, intel_pstate and intel_idle were created especially to avoid
> > ACPI, so why return to it.
> >
> > Also, the whole interface sounds like trainwreck (one would not expect
> > anything else from ACPI).
> >
> > So _why_?
> 
> The overall idea is that tying the notion of CPU performance to CPU
> frequency is no longer true these days.[1]. So, using some direction
> from an OS , the platforms want to be able to decide how to adjust CPU
> performance by using knowledge that may be very platform specific.
> e.g. through the use of performance counters, thermal budgets and
> other system specific constraints. So, CPPC describes a way for the OS
> to request performance within certain bounds and then letting the
> platform optimize it within those constraints. Expressing CPU
> performance in an abstract way, should also help keep things uniform
> across various architecture implementations.

> [1]- https://plus.google.com/+ArjanvandeVen/posts/dLn9T4ehywL
> [2] - http://git.linaro.org/people/ashwin.chaugule/leg-kernel.git/blob/236d901d31fb06fda798880c9ca09d65123c5dd9:/drivers/cpufreq/cppc_x86.c

Yeah, I'm so not clicking in that; if you want to make an argument make
it here.

In any case; that's all nice and shiny that the 'hardware' works like
that. But have these people considered how we're supposed to use it?

How should we know what to do with a new task? Do we stack it on a busy
CPU, do we wake an idle cpu and how are we going to tell which is the
'best' option.

How are we going to do DVFS like accounting if we don't know wtf the
hardware can or will do.

And how can you design these interfaces and hardware without at least
partially knowing the answer to these questions.

Content of type "application/pgp-signature" skipped