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

[Chengfeng Lin]

Hi Tianchen, Mike,

Thanks for the suggestion. Disabling DELAY_ZERO also improves the
15-worker pipe-handoff case here.

I tested the same v7.3 kernel image across three fresh boots with
DELAY_ZERO on, off, and on again. Both 333238da9a19 and DELAY_DEQUEUE
were retained. I ran context_switch1_threads with -s 15 and -t 2 or
-t 15, keeping the native CORE affinity on the same eight P-cores.

Each entry below is the mean of nine runs, using the native 15-second
post-warmup measurement window. Throughput is in millions of handoffs/s:

  Workers     On A       Off       On B     Off vs. mean of On A/B
        2    1.156     1.159      1.158             +0.17%
       15    9.172    10.425      9.165            +13.70%

The largest within-boot CV was 0.60%. The 15-worker on-again baseline
was 0.08% below the first one.

GNU time's counters from the same calls, covering the whole invocation
including warmup, also show a change in switch types. At 15 workers,
the mean involuntary share of context switches was 0.36%, 41.48%, and
0.36% for on/off/on. These results are consistent with your handoff
explanation and Mike's point that the added accounting changes
DELAY_DEQUEUE's behavior, beyond the cost of the update itself.

Thanks,
Chengfeng



On Tue, 03 Nov 2026 15:07:41 +0800, Tianchen Ding
<dtcccc@xxxxxxxxxxxxxxxxx> wrote:
> Hi Chengfeng,
>
>
> We also observed a regression in a pipe-based context-switch benchmark and
> bisected it to commit 333238da9a19 ("sched: Update time before requeueing
> delayed entities").
>
> Our working explanation is that updating curr before calculating the delayed
> wakee's lag advances the runqueue's average virtual runtime. With DELAY_ZERO
> enabled, the wakee's positive lag is clipped to zero, triggering repositioning.
> With only curr and the wakee in the same cfs_rq, this can align the wakee's
> vruntime with curr's, making both tasks eligible.
>
> Curr can then retain the CPU through slice protection. With equal weights and
> slices, the wakee's newly assigned deadline can also be later than curr's
> remaining deadline.
>
> Before this commit, the wakee would commonly preempt curr after being woken by
> curr's pipe write, while curr remained runnable. After the commit, curr
> typically continues until its subsequent read finds the reply pipe empty, then
> blocks and voluntarily switches out. We believe this change is the main cause of
> the benchmark performance regression.
>
> We observed a throughput recovery after disabling DELAY_ZERO. It would be useful
> to try this with your benchmark as well.
>
> With 333238da9a19 retained, lag compensation on delayed requeue uses up-to-date
> runtime accounting. Should we consider making DELAY_ZERO default-off?
>
> Thanks.