On 01/15/2014 01:33 PM, Michael wang wrote:
On 01/15/2014 12:07 PM, Alex Shi wrote:
Currently we just try to find least load cpu. If some cpus idled, we just pick the first cpu in cpu mask.
In fact we can get the interrupted idle cpu or the latest idled cpu, then we may get the benefit from both latency and power. The selected cpu maybe not the best, since other cpu may be interrupted during our selecting. But be captious costs too much.
So the idea here is we want to choose the latest idle cpu if we have multiple idle cpu for choosing, correct?
yes.
And I guess that was in order to avoid choosing tickless cpu while there are un-tickless idle one, is that right?
no, current logical choice least load cpu no matter if it is idle.
What confused me is, what about those cpu who just going to recover from tickless as you mentioned, which means latest idle doesn't mean the best choice, or even could be the worst (if just two choice, and the longer tickless one is just going to recover while the latest is going to tickless).
yes, to save your scenario, we need to know the next timer for idle cpu, but that is not enough, interrupt is totally unpredictable. So, I'd rather bear the coarse method now.
So what about just check 'ts->tick_stopped' and record one ticking idle cpu? the cost could be lower than time comparison, we could reduce the risk may be...(well, not so risky since the logical only works when system is relaxing with several cpu idle)
first, nohz full also stop tick. second, tick_stopped can not reflect the interrupt. when the idle cpu was interrupted, it's waken, then be a good candidate for task running.