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 06:53:15 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Ashwin Chaugule <ashwin.chaugule@...aro.org>,
	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>, 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 6:42 AM, Arjan van de Ven wrote:
> On 8/15/2014 6:08 AM, Ashwin Chaugule wrote:
>> (b) we come up with ways to provide the bounds around a Desired value
>> using the information from the platform. (long term)
>>
>> I briefly looked at the x86 HWP (Hardware Performance States) in the
>> s/w manual again. Its essentially an implementation of CPPC. It seems
>> like X86 has implemented most if not all these registers as MSRs. I'm
>> really interested in knowing if anyone there is/has been working on
>> using them and what they found.
>
> 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.
>

I should clarify this; with increasing number of cores, you end up with much more dynamic maximums
(e.g. turbo in Intel speak) and the hardware already controls this (yes the OS gives hints, but
that's mostly a lot of OS work for little value)


in a single or even dual core situation you may have a different ballgame with a small turbo range, but even in phones
octocores seem to be the norm nowadays ;-)
(just finished reading the Samsung announcement)

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