Re: [RFC] (How to) Let idle CPUs sleep

[Ingo Molnar]

* Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:

> > From all the discussions we have been having, I think a watchdog
> > implementation makes more sense. Nick/Ingo, what do you think
> > should be our final decision on this?
> 
> Well the complex solution won't go in until it is shown that the
> simple version has fundamental failure cases - but I don't think we
> need to make a final decision yet do we?

there's no need to make a final decision yet. But the more complex 
watchdog solution does have the advantage of putting idle CPUs to sleep 
immediately and perpetually.

the power equation is really easy: the implicit cost of a deep CPU sleep 
is say 1-2 msecs. (that's how long it takes to shut the CPU and the bus 
down, etc.) If we do an exponential backoff we periodically re-wake the 
CPU fully up again - wasting 1-2msec (or more) more power. With the 
watchdog solution we have more overhead on the busy CPU but it takes 
_much_ less power for a truly idle CPU to be turned off. [the true 
'effective cost' all depends on the scheduling pattern as well, but the 
calculation before is still valid.] Whatever the algorithmic overhead of 
the watchdog code, it's dwarved by the power overhead caused by false 
idle-wakeups of CPUs under exponential backoff.

the watchdog solution - despite being more complex - is also more 
orthogonal in that it does not change the balancing decisions at all - 
they just get offloaded to another CPU. The exponential backoff OTOH 
materially changes how we do SMP balancing - which might or might not 
matter much, but it will always depend on circumstances. So in the long 
run the watchdog solution is probably easier to control. (because it's 
just an algorithm offload, not a material scheduling feature.)

so unless there are strong implementational arguments against the 
watchdog solution, i definitely think it's the higher quality solution, 
both in terms of power savings, and in terms of impact.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/