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

[Tianchen Ding <dtcccc@linux.alibaba.com>]

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.