Re: [PATCH v3 7/7] sched/eevdf: Move to a single runqueue

[Mike Galbraith <efault@gmx.de>]

On Fri, 2026-11-06 at 17:43 +0100, Vincent Guittot wrote:
> 

> 333238da9a19 ("sched: Update time before requeueing delayed entities")
> fixes a bug in how the lag of a delayed dequeued task is accounted.
> 
> Let take the example of 2 tasks TA and TB running on root
...

Thanks a bunch for posting this.  Correctness trumps all else is a rare
speed bump.  The changelog didn't help discern correctness first from
booboo, the more common variety of speed bump.  This does.  I haven't
looked for sleepers surviving for tick scale distances and doing evil
deeds, will almost certainly now do so to at least get a peek at the
bug that also wants to be rendered flat.
 
> Without 333238da9a19:
> 
> - task TA  starts to sleep and is delayed dequeued with a negative lag
> of -1 usec
> - task TB becomes the current running task
> - During tick, update_curr() updates TB and moves forward its vruntime
> (and avg_vruntime) but it is still behind deadline/vprot so no
> resched().
> - TA's vruntime is now behind avg_vruntime (i.e. its lag is positive)
> - task TA wakes up just before the next tick so TB has not yet been
> updated for the last ongoing tick (up to 10ms)
>     enqueue_task_fair( TA )->requeue_delayed_entity( TA) ->
> update_entity_lag( TA ) -> TA lag is cleared and TA vruntime ==
> avg_vruntime == TB vruntime at tick N-1
>     wakeup_preempt_fair() --> update_curr_fair() -> TB vruntime is
> updated with the ongoing tick, avg_vruntime move forward by almost
> half a tick and TA now gained a positive lag of half a tick (up to 5ms
> capped by its slice) whereas it had a neg lag when it slept. This
> positive lag for TA is wrong as well as the negative lag for TB
> - Because of this wrong positive lag, TB is ineligible, and TA preempts TB.
> 
> With 333238da9a19, the main difference is that we update TB before
> updating TA lag to make sure that past exec time has been accounted.
> i.e.:
> - task TA  starts to sleep and is delayed dequeued with a negative lag
> of -1 usec
> - task TB becomes the current running task
> - During tick, update_curr() updates TB and moves forward its vruntime
> (and avg_vruntime) but it is still behind deadline/vprot so no
> resched().- TA's vruntime is now behind avg_vruntime (i.e. its lag is
> positive)
> - task TA wakes up just before the next tick so TB has not yet been
> updated for the last ongoing tick (up to 10ms)
>     enqueue_task_fair( TA )->requeue_delayed_entity( TA) ->
> update_curr() update TB
>             tehn update_entity_lag( TA ) -> TA lag is cleared and TA
> vruntime == avg_vruntime == TB vruntime at now
>     wakeup_preempt_fair() --> update_curr_fair() -> nothing to do. If
> TB is still protected by its vprot then TA does not preempt TB
> 
> That's also why when you disable DELAY_ZERO, you get the past behavior
> because we don't reset this positive lag accumulated during delayed
> dequeue. But this is still unfair... If TA has a null lag when is goes
> to sleep, it will wake with this same zero lag and will not preempt TB
> but with a -1 usec lag,  it will gain half a tick of lag (up to 5ms)
> compared to others