Re: [RFC v5 2/9] sched/deadline: improve the tracking of active utilization

From: Luca Abeni
Date: Mon Mar 27 2017 - 04:20:45 EST


On Fri, 24 Mar 2017 22:31:46 -0400
Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:

> On Fri, 24 Mar 2017 22:47:15 +0100
> luca abeni <luca.abeni@xxxxxxxxxxxxxxx> wrote:
>
> > Ok... Since I am not good at ascii art, would it be ok to add a
> > textual description? If yes, I'll add a comment like:
> > "
> > The utilization of a task is added to the runqueue's active
> > utilization when the task becomes active (is enqueued in the
> > runqueue), and is removed when the task becomes inactive. A task
> > does not become immediately inactive when it blocks, but becomes
> > inactive at the so called "0 lag time"; so, we setup the "inactive
> > timer" to fire at the "0 lag time". When the "inactive timer"
> > fires, the task utilization is removed from the runqueue's active
> > utilization. If the task wakes up again on the same runqueue before
> > the "0 lag time", the active utilization must not be changed and
> > the "inactive timer" must be cancelled. If the task wakes up again
> > on a different runqueue before the "0 lag time", then the task's
> > utilization must be removed from the previous runqueue's active
> > utilization and must be added to the new runqueue's active
> > utilization. In order to avoid races between a task waking up on a
> > runqueue while the "inactive timer" is running on a different CPU,
> > the "dl_non_contending" flag is used to indicate that a task is not
> > on a runqueue but is active (so, the flag is set when the task
> > blocks and is cleared when the "inactive timer" fires or when the
> > task wakes up).
>
> Sure, the above is great if you never want anyone to read it ;)
>
> Can you please break it up a little. My head starts to spin by the
> third line down.

Ok... Maybe finding a clean and understandable way to explain the
above sentence is something that can be done at the OSPM summit?



Thanks,
Luca