Re: [PATCH 1/6 v3] sched/fair: Set next buddy for preempt short

[Peter Zijlstra]

On Thu, Jun 25, 2026 at 02:40:34PM +0200, Vincent Guittot wrote:
> On Thu, 25 Jun 2026 at 08:24, K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
> >
> > Hello Vincent,
> >
> > On 6/24/2026 8:42 PM, Vincent Guittot wrote:
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index d78467ec6ee1..83bce5a04f3d 100644
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -9903,7 +9903,7 @@ static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_f
> > >  preempt:
> > >       if (preempt_action == PREEMPT_WAKEUP_SHORT) {
> > >               cancel_protect_slice(se);
> > > -             clear_buddies(cfs_rq, se);
> > > +             set_next_buddy(&p->se);
> > >       }
> >
> > On a tangential note, I just noticed set_preempt_buddy() has two unused
> > parameters. Seems to have been like that since it was introduced in
> > commit e837456fdca8 ("sched/fair: Reimplement NEXT_BUDDY to align with
> > EEVDF goals").
> >
> > Perhaps this can be included in the series too as a cleanup:
> 
> I would even go further and remove it. The NEXT_BUDDY feature is broken anyway

Anyway, the reason I mentioned using it, is that it only sets next if
the new entry has an earlier deadline.

But I suppose you want to violate the strict deadline order, but in that
case we should still order on slice length. We should not set next when
we already have one that is a shorter slice, no?