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.