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

[Chengfeng Lin]

Hi Mike,

Thanks for digging into this. Your point about accounting changing
DELAY_DEQUEUE's behavior fits the change in requeue frequency we reported.
I tried skipping one redundant update on v7.3 (c03c1a14507d), but it did
not improve the 15-worker case.

The change skips the leading update_curr_eevdf() in __dequeue_task()
only when pick_task_fair() has already updated the current entity and
the intervening selection has changed neither current nor the rq clock.
I passed an already-updated flag through pick_next_entity(). Ordinary
dequeue and wakeup-preemption calls still perform the update; lag,
eligibility and hierarchy accounting are unchanged.

With the same native CORE placement and 15-second post-warmup window,
15-worker throughput was 9.171 -> 9.158 -> 9.186 million handoffs/s in
baseline -> modified -> baseline runs: -0.22% against the average of
the two baselines. The 2-worker control improved by 1.27%. Each step
had nine measured runs per worker count.

Separate probes showed that the leading update on this pick path was
rare: about 1.4 calls per million handoffs at 15 workers on the baseline.
This is distinct from the frequent delayed-requeue path in our report.

Is this the path you had in mind, or were you referring to a different
update? I'd be happy to test another candidate change.

Thanks,
Chengfeng



On Fri, 30 Oct 2026 18:01:12 +0100, Mike Galbraith <efault@xxxxxx> wrote:
> 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