Messages in this thread | | | Date | Wed, 5 Dec 2012 23:19:37 +0800 | Subject | weakness of runnable load tracking? | From | Alex Shi <> |
| |
Hi Paul&Ingo:
Runnable load tracking patch set introduce a good way to tracking each entity/rq's running time. But when I try to enable it in load balance, I found burst forking many new tasks will make just few cpu heavy while other cpu has no much task assigned. That is due to the new forked task's load_avg_contrib is zero after just created. then no matter how many tasks assigned to a CPU can not increase the cfs_rq->runnable_load_avg or rq->avg.load_avg_contrib if this cpu idle. Actually, if just for new task issue, we can set new task's initial load_avg same as load_weight. but if we want to burst wake up many long time sleeping tasks, it has the same issue here since their were decayed to zero. So what solution I can thought is recording the se's load_avg_contrib just before dequeue, and don't decay the value, when it was waken up, add this value to new cfs_rq. but if so, the runnable load tracking is total meaningless. So do you have some idea of burst wakeup balancing with runnable load tracking?
-- Thanks Alex
| |