From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [RFC 0/3] Experimental patchset for CPPC Date: Fri, 15 Aug 2014 16:41:24 +0200 Message-ID: <20140815144124.GK19379@twins.programming.kicks-ass.net> References: <1408046230-16439-1-git-send-email-ashwin.chaugule@linaro.org> <20140814205143.GY6758@twins.programming.kicks-ass.net> <20140815061917.GX19379@twins.programming.kicks-ass.net> <20140815140741.GI19379@twins.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="smqHdNbl2cgnTjEa" Return-path: Content-Disposition: inline In-Reply-To: Sender: cpufreq-owner@vger.kernel.org To: Ashwin Chaugule Cc: lkml , Catalin Marinas , Mike Turquette , Morten Rasmussen , Arjan van de Ven , mingo@kernel.org, len.brown@intel.com, rjw@rjwysocki.net, "linaro-acpi@lists.linaro.org" , Arnd Bergmann , linux-acpi@vger.kernel.org, cpufreq@vger.kernel.org, Patch Tracking , Dirk Brandewie List-Id: linux-acpi@vger.kernel.org --smqHdNbl2cgnTjEa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 15, 2014 at 10:37:32AM -0400, Ashwin Chaugule wrote: > Hi Peter, >=20 > On 15 August 2014 10:07, Peter Zijlstra 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. >=20 > 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. Maybe; the guarantee and interrupt on change might be useful indeed. But which ever way we need aperf/mperf ratios somewhere. --smqHdNbl2cgnTjEa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJT7hwTAAoJEHZH4aRLwOS60ukP/1IDVKebfOGuHoOA86PFOW2i 37Mb2DkoKjMUZs1das9yySsJJlKtAHfZlIy8Meq32JHT1b0yR6kH1YWhV9lKfnGX pCov/3HCQj9fCeLisrUcseeNBhw5GScPXtcGxRn7i9BCCVo8w1/QYA14vISqFE29 wQhxhjKmPeHvgcKygmRvRWIIpxQtjoZRUTNa3BHBfwKglgY3lHTatk5WUDwNAoAc kXvcN0ZFAlP00zwoPTqG2DOqR53F9DJ0ovpFcnh5qJ+vMQts2g8ZDHuur7fXJj/p DnzoYO97t+dzWsKz3ZGFlprD4fB/BWS4PbJkR5wtNPY7+jfULf+Uu1e0L9nr44Gm QMd64kS/F/S+O5HTnUOzS3MPYfHg7LMAFG3x+SpzS7/MUitC7xPS6gV6eHVtzAM9 vEITv6GfvJSiLHbdGShx6rRFTAB/Hr4+IOcC+nckBBeAgClmLY2Rqk2bMQWjf+r+ GGTnnAsNZnysh1/77VhraOMMt/D2K6rR+nC2Jo1r1sWvd8bwFRQpzPGKN5cZLNgn 2o9qbXNYxT0XqoWySCIRnvdvMyqz8hirqv5FTB2FvcWdqwdxwEsb3tkgdzzekSZC iieltKveyfQ3miscpgxcWNrmaza4kKMnpYjSZJ6eii7ZgZwRuVbUDPwcEiFWg2RO C3VR6yzvxzplK8jSp02k =qt2F -----END PGP SIGNATURE----- --smqHdNbl2cgnTjEa--