Re: [PATCH 06/20 v3] sched/eevdf: Add min slice check when selecting CPU

[Vincent Guittot]

On Mon, 9 Nov 2026 at 15:15, Kayra Cizmeci <kayracizmeci@xxxxxxxxx> wrote:
>
> On Mon, Nov 09, 2026 at 02:55:53PM +0100, Peter Zijlstra wrote:
> > On Sat, Nov 07, 2026 at 11:57:12AM +0300, Kayra Cizmeci wrote:
> >
> > > (My editor got crazy, so I had to copy this diff :<)
> > >
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index 262626455497..8b0dd858f332 100644
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -8876,10 +8876,8 @@ static inline int sched_balance_find_dst_cpu(struct sched_domain *sd, struct tas
> > >
> > >  static inline bool choose_sched_slice_rq(struct rq *rq, struct task_struct *p)
> > >  {
> > > -   if (p->se.slice < get_rq_min_slice(rq))
> > > -           return true;
> > > -
> > > -   return false;
> > > +   return p->se.slice < get_rq_min_slice(rq) &&
> > > +           READ_ONCE(rq->curr)->sched_class == &fair_sched_class;
> > >  }
> >
> > that wants to be rcu_dereference_all() or somesuch, rather than
> > READ_ONCE().
>
> Ah, my bad :-).
>
> >
> > The think I noticed is that it will only select one slice_cpu; it will
> > not consider another once its has found one.
> >
> > This means it picks the oldest option, rather than the most recent one.

Yes, I followed the same logic as when finding an idle CPU to limit overhead.

>
> So you mean by the time CPU loop ends, the CPU that we selected
> might not be a good option anymore.
>
> > And given this is all racy as heck, the most recent one might in fact be
> > the better choice. It will have had less time to go stale.

patch 20 takes care of such situation whereas several task select the same CPU

> >
>
> Makes sense to me. So then we gonna overwrite slice_cpu everytime we
> find a new one?
>
>
> Cheers,
>
> Kayra