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

[an error occurred while processing this directive]

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJ5Y-eZiRyGroems7J2oH05ybbbivM-okm3gFz7Mkuu8ceeCDQ@mail.gmail.com>
Date:	Fri, 15 Aug 2014 10:24:32 -0400
From:	Ashwin Chaugule <ashwin.chaugule@...aro.org>
To:	Arjan van de Ven <arjan@...ux.intel.com>
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

Hi Arjan,

On 15 August 2014 09:53, Arjan van de Ven <arjan@...ux.intel.com> wrote:
> 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.
>>
>

Interesting. This sounds like X86 plans to use the Autonomous bits
that got added to the CPPC spec. (v5.1)? 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 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)
>

Going completely Autonomous (i.e. letting the platform decide whats
best w/o OS hints) may be possible only for some platforms. There will
be several ones which dont have that kind of logic built into the
hardware. In such cases getting OS hints would be the only option.

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

Yea, its getting crazy out there.

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/