Re: [PATCH v6 0/2] sched/fair: Wake short task on current CPU

[Chen Yu]

On 2023-03-15 at 17:34:43 +0800, Yicong Yang wrote:
> Hi Chenyu,
> 
> On 2023/2/22 22:09, Chen Yu wrote:
> > The main purpose is to avoid too many cross CPU wake up when it is
> > unnecessary. The frequent cross CPU wake up brings significant damage
> > to some workloads, especially on high core count systems.
> > 
> > Inhibits the cross CPU wake-up by placing the wakee on waking CPU,
> > if both the waker and wakee are short-duration tasks. The short
> > duration task could become a trouble maker on high-load system,
> > because it could bring frequent context switch. This strategy
> > only takes effect when the system is busy. Because it is unreasonable
> > to inhibit the idle CPU scan when there are still idle CPUs.
> > 
> > First, introduce the definition of a short-duration task. Then
> > leverages the first patch to choose a local CPU for wakee.
> > 
> > Overall there is performance improvement on some overloaded case.
> > Such as will-it-scale, netperf. And no noticeable impact on
> > schbench, hackbench, tbench and a OLTP workload with a commercial
> > RDBMS, tested on a Intel Xeon 2 x 56C machine.
> > 
> > Per the test on Zen3 from Prateek, most benchmarks result saw small
> > wins or are comparable to sched:tip. SpecJBB Critical-jOps improved while
> > Max-jOPS saw a small hit, but it might be in the expected range.
> > ycsb-mongodb saw small uplift in NPS1 mode.
> > 
> > Throughput improvement of netperf(localhost) was observed on a
> > Rome 2 x 64C machine, when the number of clients equals the CPUs.
> > 
> > Abel reported against a latency regression from Redis on an overloaded
> > system. Inspired by his description, v5 added the check of wakee_flips
> > to mitigate task stacking.
> > 
> > Changes since v5:
> > 1. Check the wakee_flips of the waker/wakee. If the wakee_flips
> >    of waker/wakee are both 0, it indicates that the waker and the wakee
> >    are waking up each other. In this case, put them together on the
> >    same CPU. This is to avoid that too many wakees are stacked on
> >    one CPU, which might cause regression on redis.
> > 
> 
> The patch looks good to me. And for the v6 version there's no significant
> regression on our server. :)
> 
> Detailed results below. The setup are the same as what used on v4. There're
> some gain for UDP_RR. For mysql no significant regression, there're ~2%
> loss for 128 threads case but the proportion is within the fluctuation
> range so it should be ok.
>
Thanks Yicong for the test!

thanks,
Chenyu