Re: [RFC PATCH v3 00/16] Core scheduling v3

[Subhra Mazumdar]

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?

NO_CORESCHED_STALL_FIX:

usersÂÂÂÂ %stdevÂÂ %gain %idle
16ÂÂÂÂÂÂÂ 25ÂÂÂÂÂÂ -42.4 73
24ÂÂÂÂÂÂÂ 32ÂÂÂÂÂÂ -26.3 67
32ÂÂÂÂÂÂÂ 0.2ÂÂÂÂÂ -48.9 62


CORESCHED_STALL_FIX:

usersÂÂÂÂ %stdevÂÂ %gain %idle
16ÂÂÂÂÂÂÂ 6.5ÂÂÂÂÂ -23 70
24ÂÂÂÂÂÂÂ 0.6ÂÂÂÂÂ -17 60
32ÂÂÂÂÂÂÂ 1.5ÂÂÂÂÂ -30.2ÂÂ 52