![]() | |||||||||||||
Messages in this thread |
* Nick Piggin <nickpiggin@yahoo.com.au> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-05-13 10:11 [from the cache] ©2003-2008 | |||||||||||||