On Thu, Jun 13, 2019 at 11:22 AM Julien Desfossez <jdesfos...@digitalocean.com> wrote: > > On 12-Jun-2019 05:03:08 PM, Subhra Mazumdar wrote: > > > > On 6/12/19 9:33 AM, Julien Desfossez wrote: > > >After reading more traces and trying to understand why only untagged > > >tasks are starving when there are cpu-intensive tasks running on the > > >same set of CPUs, we noticed a difference in behavior in ‘pick_task’. In > > >the case where ‘core_cookie’ is 0, we are supposed to only prefer the > > >tagged task if it’s priority is higher, but when the priorities are > > >equal we prefer it as well which causes the starving. ‘pick_task’ is > > >biased toward selecting its first parameter in case of equality which in > > >this case was the ‘class_pick’ instead of ‘max’. Reversing the order of > > >the parameter solves this issue and matches the expected behavior. > > > > > >So we can get rid of this vruntime_boost concept. > > > > > >We have tested the fix below and it seems to work well with > > >tagged/untagged tasks. > > > > > My 2 DB instance runs with this patch are better with CORESCHED_STALL_FIX > > than NO_CORESCHED_STALL_FIX in terms of performance, std deviation and > > idleness. May be enable it by default? > > Yes if the fix is approved, we will just remove the option and it will > always be enabled. >
sysbench --report-interval option unveiled something. benchmark setup ------------------------- two cgroups, cpuset.cpus = 1, 53(one core, two siblings) sysbench cpu mode, one thread in cgroup1 sysbench memory mode, one thread in cgroup2 no core scheduling -------------------------- cpu throughput eps: 405.8, std: 0.14% mem bandwidth MB/s: 5785.7, std: 0.11% cgroup1 enable core scheduling(cpu mode) cgroup2 disable core scheduling(memory mode) ----------------------------------------------------------------- cpu throughput eps: 8.7, std: 519.2% mem bandwidth MB/s: 6263.2, std: 9.3% cgroup1 disable core scheduling(cpu mode) cgroup2 enable core scheduling(memory mode) ----------------------------------------------------------------- cpu throughput eps: 468.0 , std: 8.7% mem bandwidth MB/S: 311.6 , std: 169.1% cgroup1 enable core scheduling(cpu mode) cgroup2 enable core scheduling(memory mode) ---------------------------------------------------------------- cpu throughput eps: 76.4 , std: 168.0% mem bandwidth MB/S: 5388.3 , std: 30.9% The result looks still unfair, and particularly, the variance is too high, ----sysbench cpu log ---- ----snip---- [ 10s ] thds: 1 eps: 296.00 lat (ms,95%): 2.03 [ 11s ] thds: 1 eps: 0.00 lat (ms,95%): 1170.65 [ 12s ] thds: 1 eps: 1.00 lat (ms,95%): 0.00 [ 13s ] thds: 1 eps: 0.00 lat (ms,95%): 0.00 [ 14s ] thds: 1 eps: 295.91 lat (ms,95%): 2.03 [ 15s ] thds: 1 eps: 1.00 lat (ms,95%): 170.48 [ 16s ] thds: 1 eps: 0.00 lat (ms,95%): 2009.23 [ 17s ] thds: 1 eps: 1.00 lat (ms,95%): 995.51 [ 18s ] thds: 1 eps: 296.00 lat (ms,95%): 2.03 [ 19s ] thds: 1 eps: 1.00 lat (ms,95%): 170.48 [ 20s ] thds: 1 eps: 0.00 lat (ms,95%): 2009.23 ----snip---- Thanks, -Aubrey