Re: [PATCH 4/8] sched/eevdf: Decay positive lag of sleeping entities

[Vincent Guittot]

On Tue, 22 Sept 2026 at 15:29, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Tue, Sep 22, 2026 at 02:56:56PM +0200, Vincent Guittot wrote:
> > On Tue, 22 Sept 2026 at 12:02, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> > > On Mon, Sep 21, 2026 at 05:22:34PM +0200, Vincent Guittot wrote:
>
> > > > +
> > > > +     vlag -= calc_delta_fair(delta_exec, se);
> > >
> > > Should this not be 'W+w' at the very least?, ideally it would be the
> > > complete sum of all decaying weight rather than just 'w', but that might
> > > be a tad tricky.
> >
> > I spent some time thinking about this. The right solution should be
> > the one you suggested in your next reply: keeping the sleeping tasks
> > "enqueued" in another tree and computing a zero decay vruntime.
> > However, I was afraid of the overhead of managing this new tree and
> > taking the lock of another rq to dequeue the task.
>
> Yeah :/
>
> > Anything else in
> > between will be an approximation because W at enqueue doesn't reflect
> > what happened during the sleep period: The CPU could have been idle
> > the entire time,
>
> Ah but if we let idle reset all the lags, by sequence number or anything
> else, then that case doesn't matter.
>
> > but several tasks wake up simultaneously so the 1st
> > enqueued will not see a W whereas the other one will.
>
> Right. So this approximation is under estimating, it is the absolute
> lowest possible decay time, which seems somewhat unfortunate. OTOH I
> agree that keeping the whole second tree and all that comes with that,
> might be a tad much.
>
> Still it would be good to find a more reasonable approach. Perhaps using
> load_avg ? I think over-estimating it might be a little safer than
> under-estimating in this case.

I'm going to study this further