On 11/22/2013 05:57 PM, Morten Rasmussen wrote:
On Thu, Nov 21, 2013 at 12:22:06PM +0000, Alex Shi wrote:
Add Daniel and remove Diane. sorry.
On 11/21/2013 04:34 PM, Alex Shi wrote:
When I read the runnable load avg code, I found the task's avg.load_avg_contrib mainly updated in enqueue/dequeue, and the 'curr' task in sched_tick. So, if a sleep long time task is waked/added and kept on a cpu, but the task is never be the 'curr' in sched_tick. Then the task's load contrib will never be updated and keep small.
what I missed? or Is it really?
It is correct that the task load_avg_contrib is updated at enqueue/dequeue and when it happens to be 'curr' at the sched_tick. Additionally it is updated every time the task is descheduled as part of put_prev_entity() which is called from __schedule() (through other functions).
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. :)
load_avg_contrib is not updated while the task is sleeping. It will be updated when the task is reinserted into a runqueue at wakeup. That fact that is retains its old (non-decayed) value is a very useful feature as it allows us to see how the task behaved last time it ran no matter how long it has been sleeping. That is not currently exploited in the mainline scheduler, but it is very important for energy-aware scheduling (and big.LITTLE scheduler support).
For example, webbrowser rendering it quite cpu intensive but doesn't happen very often. So its 'true' load_avg_contrib would be 0, but since it isn't updated we can see that it ran for a long time last time it was scheduled and schedule it on an appropriate cpu instead of assuming that it is a small task.
Yes. If such scenarios happens often, maybe worthy to add a new load_avg_contrib variable to store the old value that you wanted.