On 4 June 2014 11:23, Peter Zijlstra peterz@infradead.org wrote:
On Wed, Jun 04, 2014 at 09:55:42AM +0100, Morten Rasmussen wrote:
Both running_avg and runnable_avg are affected by other tasks on the same cpus, but in different ways. They are equal if you only have one task on a cpu. If you have more, running_avg will give you the true requirement of the tasks until the cpu is fully utilized. At which point the task running_avg will drop if you add more tasks (the unweighted sum of task running_avgs remains constant).
runnable_avg on the other hand, might be affected as soon as you have two task running on the same cpu if they are runnable at the same time. That isn't necessarily a bad thing for load-balancing purposes, because tasks that are runnable at the same time are likely to be run more efficiently by placing them on different cpus. You might view as at sort of built in concurrency factor, somewhat similar to what Yuyang is proposing. runnable_avg increases rapidly when the cpu is over-utilized.
Agreed.
I'm not sure I see how 100% is possible, but yes I agree that runnable can indeed be inflated due to this queueing effect.
You should only be able to get to 75% worst case for runnable_avg for that example. The total running_avg is 50% no matter if the tasks overlaps or not.
Yes, 75% is what I ended up with.
Can you explain how you reach 75% as it depends on the runtime and a runtime longer than 345ms will end to a 100% load whatever the idletime was previously ?
f you had five tasks on one cpu that each have a 25% requirement you can get individual task runnable_avgs of up to 100% (cpu unweighted runnable_load_avg can get up 500%, I think), but the task running_avgs would be 20% each (total of 100%).
Yeah, more or less so indeed. I had not considered the queueing effects on runnable_avg yesterday, so good that that got raised.
That does indeed invalidate my: runnable - running := extra cpu required thing. It ends up being the extra cpu required for 0 latency but gobs of idle time, which is something else entirely.