Re: [Ksummit-discuss] [TECH(CORE?) TOPIC] Energy conservation bias interfaces

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Monday, May 12, 2014 09:36:15 PM Preeti U Murthy wrote:
> On 05/08/2014 07:53 PM, Iyer, Sundar wrote:
> >> -----Original Message-----
> >> From: Preeti U Murthy [mailto:preeti@linux.vnet.ibm.com]
> >> Sent: Thursday, May 8, 2014 2:30 PM
> >> To: Iyer, Sundar; Peter Zijlstra; Rafael J. Wysocki
> >> Cc: Brown, Len; Daniel Lezcano; Ingo Molnar; ksummit-

[cut]

> 
> The cpuidle sub-system is behaving fairly well on some of the platforms.
> A lot of CPU  power management is platform specific. But by exposing
> arch specific details like the details about the idle states that are
> present, through the cpuidle drivers, the kernel is able to make
> reasonably good predictions about the duration of idleness of a cpu and
> choose the idle state that it must enter into.
>   The point is that we have succeeded in the past in getting the high
> level power management reasonably right in the kernel although they were
> platform dependent.

The problem had fewer dimensions then (so to speak), however.

The set of available C-states might be different, but that pretty much was
all that needed to be taken into account.

Today, there are C-states per core, per package (also per module on some
platforms and so on) and there may be platform dependencies (like some
C-states are not available if certain I/O devices are not in the "right"
states).  That makes the picture a bit less clean and there are more
places where tradeoffs come into play, at least potentially.

Let alone the whole C-states vs P-states issue (Is it better to run at a
lower frequency for time X, or is it better to run at a higher frequency
for time Y, Y < X?).

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.