Re: [RFC PATCH v3 00/16] Core scheduling v3
From: Julien Desfossez
Date: Thu Jun 13 2019 - 12:57:06 EST
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.