Re: [PATCH v3 09/12] Revert "sched: Put rq's sched_avg under CONFIG_FAIR_GROUP_SCHED"

[Vincent Guittot]

On 10 July 2014 15:16, Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/