On 10 July 2014 15:16, Peter Zijlstra peterz@infradead.org wrote:
On Mon, Jun 30, 2014 at 06:05:40PM +0200, Vincent Guittot wrote:
This reverts commit f5f9739d7a0ccbdcf913a0b3604b134129d14f7e.
We are going to use runnable_avg_sum and runnable_avg_period in order to get the utilization of the CPU. This statistic includes all tasks that run the CPU and not only CFS tasks.
But this rq->avg is not the one that is migration aware, right? So why use this?
Yes, it's not the one that is migration aware
We already compensate cpu_capacity for !fair tasks, so I don't see why we can't use the migration aware one (and kill this one as Yuyang keeps proposing) and compensate with the capacity factor.
The 1st point is that cpu_capacity is compensated by both !fair_tasks and frequency scaling and we should not take into account frequency scaling for detecting overload
What we have now is the the weighted load avg that is the sum of the weight load of entities on the run queue. This is not usable to detect overload because of the weight. An unweighted version of this figure would be more usefull but it's not as accurate as the one I use IMHO. The example that has been discussed during the review of the last version has shown some limitations
With the following schedule pattern from Morten's example
| 5 ms | 5 ms | 5 ms | 5 ms | 5 ms | 5 ms | 5 ms | 5 ms | 5 ms | A: run rq run ----------- sleeping ------------- run B: rq run rq run ---- sleeping ------------- rq
The scheduler will see the following values: Task A unweighted load value is 47% Task B unweight load is 60% The maximum Sum of unweighted load is 104% rq->avg load is 60%
And the real CPU load is 50%
So we will have opposite decision depending of the used values: the rq->avg or the Sum of unweighted load
The sum of unweighted load has the main advantage of showing immediately what will be the relative impact of adding/removing a task. In the example, we can see that removing task A or B will remove around half the CPU load but it's not so good for giving the current utilization of the CPU
Vincent