Re: [RFC 0/3] Experimental patchset for CPPC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Hi Arjan,

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

To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux