charged with putting the CPU into the optimal sleep state when there is
nothing for it to do. One of the key inputs into this decision is the next
scheduled timer event; that event puts an upper bound on how long the
processor can expect to be able to sleep undisturbed. A more distant next
timer event suggests that a deeper sleep state is appropriate.
But timer events are not the only way to wake up a processor; device
interrupts will also do that. There are times when hardware can be
expected to interrupt well before the next timer expiration, but those
times can be hard for the processor to predict. There is seemingly an
exception, though: sometimes hardware interrupts are so regular that they
become a sort of timer tick in their own right. A moving mouse can
generate that sort of pattern; network traffic can do it too. In such
situations, the current cpuidle "menu" governor may repeatedly choose the
wrong sleep state.
Arjan van de Ven has come to the rescue with a simple cpuidle patch which
maintains an array of the last eight actual sleep periods. Whenever it is
time to put the processor to sleep, the standard deviation of those sleep
periods is calculated; if it is small, then the average sleep is considered
to be a better guide to the expected sleep period than the next timer
As machine learning goes, this code is a relatively simple example. But it
should be smart enough to catch simple patterns and run the hardware in
something closer to an optimal mode.
to post comments)