Re: [PATCH v2 10/10] sched/eevdf: Move to a single runqueue

[Peter Zijlstra]

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.

Since all the actual running happens inside R, this is what is required
by update_entity_lag().

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.

> > +       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;