Re: [PATCH 3/6 v2] sched/eevdf: Update slice protection even when resched is already set

[Vincent Guittot]

On Tue, 16 Jun 2026 at 11:37, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Mon, Jun 15, 2026 at 06:24:17PM +0200, Vincent Guittot wrote:
> > Even if resched is already set, we might want to update or even cancel
> > the slice protection and ensure that the newly waking task will be the
> > next one to run.
> >
> > Signed-off-by: Vincent Guittot <vincent.guittot@xxxxxxxxxx>
> > ---
> >  kernel/sched/fair.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index b8d5d9bcc014..b98d67650a98 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -9805,7 +9805,7 @@ static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_f
> >        * prevents us from potentially nominating it as a false LAST_BUDDY
> >        * below.
> >        */
> > -     if (test_tsk_need_resched(rq->curr))
> > +     if (!sched_feat(PREEMPT_SHORT) && test_tsk_need_resched(rq->curr))
> >               return;
> >
> >       if (!sched_feat(WAKEUP_PREEMPTION))
>
> Fair enough.
>
> It did get me thinking about what we would want for SCHED_BATCH tasks. I
> think we might want to make that RUN_TO_PARITY check (which selects
> min_slice) conditional on normal_policy(). But that's another patch for
> another day (and much easier after we land that flat thing).

Patch 5 forces the update even for sched idle and batch because even
if they don't preempt current, we don't want them to increase their
lag to an unmanageable level by the time a short slice task wakes up.
Something similar to my example in patch 2
>
>