Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [RFC PATCH v3 00/16] Core scheduling v3
To:     Julien Desfossez <jdesfossez@digitalocean.com>,
        Aaron Lu <aaron.lu@linux.alibaba.com>
Cc:     Aubrey Li <aubrey.intel@gmail.com>,
        Vineeth Remanan Pillai <vpillai@digitalocean.com>,
        Nishanth Aravamudan <naravamudan@digitalocean.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Ingo Molnar <mingo@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Paul Turner <pjt@google.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
        =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= <fweisbec@gmail.com>,
        Kees Cook <keescook@chromium.org>,
        Greg Kerr <kerrnel@google.com>, Phil Auld <pauld@redhat.com>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Mel Gorman <mgorman@techsingularity.net>,
        Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
        Paolo Bonzini <pbonzini@redhat.com>
References: <cover.1559129225.git.vpillai@digitalocean.com>
 <CAERHkruDE-7R5K=2yRqCJRCpV87HkHzDYbQA2WQkruVYpG7t7Q@mail.gmail.com>
 <e8872bd9-1c6b-fb12-b535-3d37740a0306@linux.alibaba.com>
 <20190531210816.GA24027@sinkpad> <20190606152637.GA5703@sinkpad>
 <20190612163345.GB26997@sinkpad>
From:   Subhra Mazumdar <subhra.mazumdar@oracle.com>
Message-ID: <635c01b0-d8f3-561b-5396-10c75ed03712@oracle.com>
Date:   Wed, 12 Jun 2019 17:03:08 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <20190612163345.GB26997@sinkpad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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