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

[Subhra Mazumdar <subhra.mazumdar@oracle.com>]

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