Re: [PATCH v2 10/10] sched/eevdf: Move to a single runqueue
From: Vincent Guittot
Date: Thu May 21 2026 - 10:17:31 EST
On Thu, 21 May 2026 at 15:29, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Thu, May 21, 2026 at 02:13:48PM +0200, Vincent Guittot wrote:
>
> > > Would it not be simpler to just move the update_entity_lag() call up a
> > > bit, like so?
> > >
> > > ---
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -7999,6 +7999,9 @@ static bool __dequeue_task(struct rq *rq
> > >
> > > clear_buddies(cfs_rq, se);
> > >
> > > + update_curr(cfs_rq);
> >
> > I agree it's simpler although we will call update_curr twice for one
> > level, but the 2nd call should be nop because of delta_exec being null
> >
> > Prateek proposed update_curr(task_cfs_rq(p)). Using task_cfs_rq(p)
> > will ensure that we keep the same ordering as for_each_sched_entity
>
> Given:
>
> R
> |
> G
> |
> t
>
> Then task_cfs_rq() will be G's cfs_rq, while cfs_rq is R's cfs_rq.
Yes but update_curr() moves to R's cfs anyway before updating
vruntime, deadline and dl_server
>
> Since all the actual running happens inside R, this is what is required
> by update_entity_lag().
In other places like task_tick_fair, we follow the G then R order and
vruntime and deadline are updated while updating G
>
> Doing update_curr(task_cfs_rq()) here doesn't make sense.
>
> I'm not sure I see a way in which running them out of order hurts
> anything.
I was thinking of use cases which involves throttling but I haven't
gone deeply in the analyses
>
> > > + update_entity_lag(cfs_rq, se);
> > > +
> > > if (flags & DEQUEUE_DELAYED) {
> > > WARN_ON_ONCE(!se->sched_delayed);
> > > } else {
> > > @@ -8022,7 +8025,6 @@ static bool __dequeue_task(struct rq *rq
> > >
> > > dequeue_hierarchy(p, flags);
> > >
> > > - update_entity_lag(cfs_rq, se);
> > > if (sched_feat(PLACE_REL_DEADLINE) && !task_sleep) {
> > > se->deadline -= se->vruntime;
> > > se->rel_deadline = 1;