Re: [RFCv6 PATCH 09/10] sched: deadline: use deadline bandwidth in scale_rt_capacity

[Luca Abeni]

Hi Vincent,

first of all, thanks for adding me in the discussion.

On 12/09/2015 09:50 AM, Vincent Guittot wrote:
> adding Lucas
>
> On 9 December 2015 at 07:19, Steve Muckle <steve.muckle@xxxxxxxxxx> wrote:
> > From: Vincent Guittot <vincent.guittot@xxxxxxxxxx>
> >
> > Instead of monitoring the exec time of deadline tasks to evaluate the
> > CPU capacity consumed by deadline scheduler class, we can directly
> > calculate it thanks to the sum of utilization of deadline tasks on the
> > CPU.  We can remove deadline tasks from rt_avg metric and directly use
> > the average bandwidth of deadline scheduler in scale_rt_capacity.
> >
> > Based in part on a similar patch from Luca Abeni <luca.abeni@xxxxxxxx>.
Just to check if my understanding of your patch is correct: what you do is
to track the total utilisation of the tasks that are assigned to a CPU/core,
independently from their state (active or inactive). The difference with my
patch is that I try to track the "active utilisation" (eliminating the utilisation
of the tasks that are blocked).

Is this understanding correct?
If yes, I think your approach is safe (and easier to implement - modulo a small
issue when a task terminates of switches to other scheduling policies; I think
there already are some "XXX" comments in the current code). However, it allows to
save less energy (or reclaim less CPU time). For example, if I create a SCHED_DEADLINE
task with runtime 90ms and period 100ms it will not allow to scale the CPU frequency
even if it never executes (because is always blocked).


[...]
> > +       /* This is the "average utilization" for this runqueue */
> > +       s64 avg_bw;
> >   };
Small nit: why "average" utilization? I think a better name would be "runqueue utilization"
or "local utilization", or something similar... If I understand correctly (sorry if I
missed something), this is not an average, but the sum of the utilisations of the tasks
on this runqueue... No?



				Luca
--
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/