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

[Kayra Cizmeci <kayracizmeci@gmail.com>]

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.

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.
> 

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


Cheers,

Kayra