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. Thanks, Julien
