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

[Mike Galbraith <efault@gmx.de>]

On Fri, 2026-10-30 at 21:03 +0800, Chengfeng Lin wrote:
> Hi Vincent, Mike, Peter,
> 
> I have additional pipe-handoff throughput results for 333238da9a19
> ("sched: Update time before requeueing delayed entities"), which Mike
> identified in his wakeup-jitter test [1]. With 15 workers, will-it-scale
> throughput on v7.3 is 15.69% lower than v7.1.3 in thread mode and 14.82%
> lower in process mode. Reverting this commit on v7.2 in a separate controlled
> comparison improves 15-worker thread throughput by 13.65%; the 2-worker
> control changes by -0.48%.

After much crawling over trees etc, and way more yacking than intended
for a datapoint, I think I know what's up, and it's simple: there's a
good reason those "now" updates are event driven.  That one was added
in the DELAY_DEQUEUE machinery, where it expends and *banks* precious
fastpath cycles, shifting bean counting enough to make DELAY_DEQUEUE
measurably less effective.  It looks completely broken with a 20% util
probe, but more measurement shows that it's not dead, just a bit sad.

Test probe sent another signal in virgin flat in __dequeue_task(), and
I think it's valid for that update_curr() too. It seems to be in
keeping with placement strategy, but with flat changes, we just updated
the cfs_rq where all the action is, and hierarchy update is right below
it.. looks like redundant overhead.

	-Mike