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.
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.