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

[Morten Rasmussen <morten.rasmussen@arm.com>]

On Thu, May 08, 2014 at 03:23:58PM +0100, 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-
> 
> > True that 'race to halt' also ends up saving energy. But when the kernel goes
> > conservative on energy, the scheduler would look at racing to idle *within a
> > power domain* as much as possible. Only if the load crosses a certain
> > threshold would it spread across to other power domains.
> 
> I think Rafael mentioned in an another thread about shared supplies and resources.
> In such a case, the race-to-idle within a power domain may actually negate the overall
> platform savings.
> 
> And to confirm, you are referring to generic power domains beyond the CPU right?
> 
> > These are general heuristics. These simple heuristics must work out for most
> > platforms but may not work for all. If it works for majority of the cases then
> > I believe we can safely call it a success.
> 
> And which is why I mentioned that this is heavily platform dependent. This is 
> completely dependent on how the rest of the system power management works.

Agree. Race to halt/idle is not universally a good idea. It depends of
the platform energy efficiency at the higher performance states, idle
power consumption, system topology, use-case, and anything else that
consumes power while the tasks are running. For example, if your energy
efficiency is really bad in the turbo states, it might be worth going a
bit slower if the total energy can be reduced.