Re: Usecases for the per-task latency-nice attribute

[Vincent Guittot]

On Wed, 18 Sep 2019 at 17:46, Patrick Bellasi <patrick.bellasi@xxxxxxx> wrote:
>
>
> On Wed, Sep 18, 2019 at 16:22:32 +0100, Vincent Guittot wrote...
>
> > On Wed, 18 Sep 2019 at 16:19, Patrick Bellasi <patrick.bellasi@xxxxxxx> wrote:
>
> [...]
>
> >> $> Wakeup path tunings
> >> ==========================
> >>
> >> Some additional possible use-cases was already discussed in [3]:
> >>
> >>  - dynamically tune the policy of a task among SCHED_{OTHER,BATCH,IDLE}
> >>    depending on crossing certain pre-configured threshold of latency
> >>    niceness.
> >>
> >>  - dynamically bias the vruntime updates we do in place_entity()
> >>    depending on the actual latency niceness of a task.
> >>
> >>    PeterZ thinks this is dangerous but that we can "(carefully) fumble a
> >>    bit there."
> >
> > I agree with Peter that we can easily break the fairness if we bias vruntime
>
> Just to be more precise here and also to better understand, here I'm
> talking about turning the tweaks we already have for:
>
>  - START_DEBIT
>  - GENTLE_FAIR_SLEEPERS

ok. So extending these 2 features could make sense

>
> a bit more parametric and proportional to the latency-nice of a task.
>
> In principle, if a task declares a positive latency niceness, could we
> not read this also as "I accept to be a bit penalised in terms of
> fairness at wakeup time"?

I would say no. It's not because you declare a positive latency
niceness that you should lose some fairness and runtime. If task
accept long latency because it's only care about throughput, it
doesn't want to lost some running time

>
> Whatever tweaks we do there should affect anyway only one sched_latency
> period... although I'm not yet sure if that's possible and how.
>
> >>  - bias the decisions we take in check_preempt_tick() still depending
> >>    on a relative comparison of the current and wakeup task latency
> >>    niceness values.
> >
> > This one seems possible as it will mainly enable a task to preempt
> > "earlier" the running task but will not break the fairness
> > So the main impact will be the number of context switch between tasks
> > to favor or not the scheduling latency
>
> Preempting before is definitively a nice-to-have feature.
>
> At the same time it's interesting a support where a low latency-nice
> task (e.g. TOP_APP) RUNNABLE on a CPU has better chances to be executed
> up to completion without being preempted by an high latency-nice task
> (e.g. BACKGROUND) waking up on its CPU.
>
> For that to happen, we need a mechanism to "delay" the execution of a
> less important RUNNABLE task up to a certain period.
>
> It's impacting the fairness, true, but latency-nice in this case will
> means that we want to "complete faster", not just "start faster".

you TOP_APP task will have to set both nice and latency-nice  if it
wants to make (almost) sure to have time to finish before BACKGROUND


>
> Is this definition something we can reason about?
>
> Best,
> Patrick
>
> --
> #include <best/regards.h>
>
> Patrick Bellasi