* Nick Piggin <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
