On Wed, Nov 27, 2013 at 06:52:22AM +0000, Alex Shi wrote:
load_avg_contrib should always be quite close to the 'true' value as long as it is running. It would be updated at least once per sched period.
I read the code again. yes if the task was scheduled(sum_exec_runtime increased), the load_avg_period will be updated. But if the task is just in running queue without a chance to take cpu, the load_avg_contrib still keep the old value when it was inserted into running queue. It seems not a big deal, if the task has chance to run. but if there is much of tasks in system, and lots of such task(with a little load_avg_contrib) waiting on a cpu. the cpu_load will not be correct -- smaller then expected. then that make load balance do wrong decision: give this cpu more tasks. That will be worse. :)
I'm confused by what you mean it "keeps" the old value.
When a task blocks, it's load_contrib is removed from runnable_load_avg. This quantity is moved to blocked_load_avg, and continues to be updated (specifically: decayed since the task is not contributing load while blocked). When the task wakes back up its load_contrib is updated to match the decay charged against it.
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.