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

[Vincent Guittot]

On Fri, 26 Jun 2026 at 08:54, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> 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

yeah, and make sure that next is eligible

> case we should still order on slice length. We should not set next when
> we already have one that is a shorter slice, no?

set_next_buddy() is only called for PREEMPT_WAKEUP_SHORT which is only
used when (pse->slice < se->slice) with this patchset