On Wed, Nov 27, 2013 at 01:35:39PM +0000, Alex Shi wrote:
On 11/27/2013 07:39 PM, Morten Rasmussen wrote:
Yes. when the task is not in running queue, it's load in blocked_load and was decay correctly. I just concern a very rarely scenario: a sleep long time task was added into running queue, so its load_contrib is nearly 0, but it isn't get real cpu for long time. then I am afraid its load_contrib has no chance to be updated.
All tasks gets a chance to run at least once per sched_period. The period is dynamically extended depending on the number of running tasks. It may therefore take a while until the task is scheduled if you have many tasks running. But, if your task has been sleeping for a long time its vruntime is quite likely to place the task near the head of the runqueue and the waiting time is much shorter than a sched_period.
If you have that many tasks small errors in the load_contrib is probably not your biggest concern.
Thanks for explanation, Morten! We may assume there are 2 cpus in system, one has 100, another has 10 normal tasks.
cpu0: 100 tasks * each task's load_contrib: 1 (all tasks just wakeup from sleep), the load of cpu0 is 100 * 1 = 100 cpu1: 10 tasks * each task's load: 1000, the load cpu1 is 10 * 1000 = 10000
the typical LB interval is a few ms, assume 1 ms the min_granularity is 0.75ms. assume 1ms. So after 1ms, LB happened, cpu0 load = (100-1) * 1 + L(t) here L(t) = 1024(task load) * 1002 / 47742 = 99 + 21 = 120 cpu1 load = 10000 then, LB want to move move half of tasks to cpu0. That is a wrong decision. after 2ms, cpu0 load = 120 + 500 + 21 cpu1 load = 500 then LB still will do incorrect decision.
I'm not sure if it its a wrong decision. The load-balancer can not do better with the information it has available. We would need a better way to predict future task behaviour to do better.
In the above scenario the balance will eventually sort itself out, but it may take a while as the load is quite extreme.
Above scenario is rare to happen, but that show, in this corner case(prediction wrong), system need more time/CS to rebalance well.
But I agree that is not a big deal, since this scenario is hard to have.
There will always be cases that defeat the load-balancing algorithm. You could probably fix that particular case by doing tricks similar to one I described in the other email for big.LITTLE. However, you risk introducing new cases of undesirable behaviour.
An even easier fix for this particular problem is to just go back and use the static load.weight for load-balancing. :)