Re: [PATCH v2 5/7] sched/fair: Take into account latency nice at wakeup

[Vincent Guittot <vincent.guittot@linaro.org>]

On Thu, 19 May 2022 at 22:07, Josh Don <joshdon@google.com> wrote:
>
> On Thu, May 19, 2022 at 6:57 AM Vincent Guittot
> <vincent.guittot@linaro.org> wrote:
> >
> > On Tue, 17 May 2022 at 02:54, Josh Don <joshdon@google.com> wrote:
> > >
> > > Hi Vincent,
> > >
> > > On Thu, May 12, 2022 at 9:36 AM Vincent Guittot
> > > <vincent.guittot@linaro.org> wrote:
> > > >
> > > > Take into account the nice latency priority of a thread when deciding to
> > > > preempt the current running thread. We don't want to provide more CPU
> > > > bandwidth to a thread but reorder the scheduling to run latency sensitive
> > > > task first whenever possible.
> > > >
> > > > As long as a thread didn't use its bandwidth, it will be able to preempt
> > > > the current thread.
> > > >
> > > > At the opposite, a thread with a low latency priority will preempt current
> > > > thread at wakeup only to keep fair CPU bandwidth sharing. Otherwise it will
> > > > wait for the tick to get its sched slice.
> > >
> > > Following up from the discussion on the prior series, I'm still not
> > > sure why this approach is exclusive of extending the entity placement
> > > code; I think both changes together would be useful.
> > >
> > > By only changing the wakeup preemption decision, you're only
> > > guaranteeing that the latency-sensitive thing on cpu won't be
> > > preempted until the next sched tick, which can occur at any time
> > > offset from the wakeup, from 0ns to the length of one tick. If a
> >
> > In fact, you are ensured to run a minimum time of 3ms at least on >=8
> > cores system before tick can preempt you. I considered updating this
> > part as well to increase the value for negative weight but didn't do
> > it for now. I can have a look
>
> If the latency sensitive thing on cpu has already been running close
> to or greater than that min granularity, that doesn't apply; can still
> get preempted pretty quickly from the tick by the newly woken task.

The 3ms is ensured from the task wakeup whatever the previous run and
whatever can wakeup in the mean time but didn't preempt it at wakeup.
As mentioned above, it is probably worth having this value scale with
latency, especially for low latency task.

>
> A possible change would be to reduce the sleeper credit when the
> waking entity has lower latency priority than the current entity (ie.
> similar to the se_is_idle() check already being made in
> place_entity()).
>
> > > latency-tolerant task wakes up with a lot of sleeper credit, it would
> > > pretty quickly preempt a latency-sensitive task on-cpu, even if it
> > > doesn't initially do so due to the above changes to wakeup preemption.
> > >
> > > Adjusting place_entity wouldn't impact cpu bandwidth in steady-state
> > > competition between threads of different latency prio, it would only
> > > impact slightly at wakeup, in a similar but more consistent manner to
> > > the changes above to wakeup_preempt_entity (ie. a task that is not
> > > latency sensitive might have to wait a few ticks to preempt a latency
> > > sensitive task, even if it was recently sleeping for a while).