linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Chris Mason" <clm@fb.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Rik van Riel <riel@surriel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fix scheduler regression from "sched/fair: Rework load_balance()"
Date: Mon, 26 Oct 2020 11:28:43 -0400	[thread overview]
Message-ID: <E3EBECF9-D16E-4D5B-B4F7-675B42624F19@fb.com> (raw)
In-Reply-To: <83A9BEDF-20BB-4BAD-AABD-0EECB92BF8DF@fb.com>

On 26 Oct 2020, at 11:05, Chris Mason wrote:

> On 26 Oct 2020, at 10:24, Vincent Guittot wrote:
>
>>
>> Could you try the fix below ?
>>
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -9049,7 +9049,8 @@ static inline void calculate_imbalance(struct 
>> lb_env *env, struct sd_lb_stats *s
>>          * emptying busiest.
>>          */
>>         if (local->group_type == group_has_spare) {
>> -               if (busiest->group_type > group_fully_busy) {
>> +               if ((busiest->group_type > group_fully_busy) &&
>> +                   (busiest->group_weight > 1)) {
>>                         /*
>>                          * If busiest is overloaded, try to fill 
>> spare
>>                          * capacity. This might end up creating spare 
>> capacity
>>
>>
>> When we calculate an imbalance at te smallest level, ie between CPUs 
>> (group_weight == 1),
>> we should try to spread tasks on cpus instead of trying to fill spare 
>> capacity.
>
> With this patch on top of v5.9, my latencies are unchanged.  I’m 
> building against current Linus now just in case I’m missing other 
> fixes.
>

I reran things to make sure the nothing changed on my test box this 
weekend:

5.4.0-rc1-00009-gfcf0553db6f4 (last good kernel)
Latency percentiles (usec) runtime 30 (s) (1000 total samples)
         50.0th: 180 (502 samples)
         75.0th: 227 (251 samples)
         90.0th: 268 (147 samples)
         95.0th: 300 (50 samples)
         *99.0th: 338 (41 samples)
         99.5th: 344 (4 samples)
         99.9th: 1186 (5 samples)
         min=25, max=1185

5.4.0-rc1-00010-g0b0695f2b34a (first bad kernel)
Latency percentiles (usec) runtime 150 (s) (960 total samples)
         50.0th: 166 (488 samples)
         75.0th: 210 (232 samples)
         90.0th: 254 (145 samples)
         95.0th: 299 (47 samples)
         *99.0th: 12688 (39 samples)
         99.5th: 13008 (5 samples)
         99.9th: 13104 (4 samples)
         min=24, max=13100

3650b228f83adda7e5ee532e2b90429c03f7b9ec (v5.10-rc1) + your patch

Latency percentiles (usec) runtime 30 (s) (1000 total samples)
         50.0th: 169 (505 samples)
         75.0th: 210 (246 samples)
         90.0th: 267 (151 samples)
         95.0th: 305 (48 samples)
         *99.0th: 12656 (40 samples)
         99.5th: 12944 (5 samples)
         99.9th: 13168 (5 samples)
         min=44, max=13155

-chris

      parent reply	other threads:[~2020-10-26 15:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-23 23:49 [PATCH] fix scheduler regression from "sched/fair: Rework load_balance()" Chris Mason
2020-10-26  8:39 ` Vincent Guittot
2020-10-26 12:45   ` Chris Mason
2020-10-26 14:24     ` Vincent Guittot
2020-10-26 14:38       ` Rik van Riel
2020-10-26 14:56         ` Vincent Guittot
2020-10-26 15:04           ` Rik van Riel
2020-10-26 15:42             ` Vincent Guittot
2020-10-26 15:54               ` Vincent Guittot
2020-10-26 16:04               ` Rik van Riel
2020-10-26 16:20                 ` Vincent Guittot
2020-10-26 16:48                   ` Chris Mason
2020-10-26 16:52                     ` Vincent Guittot
2020-10-30  2:10                       ` Rik van Riel
2020-10-30  9:16                         ` Vincent Guittot
2020-10-26 15:05       ` Chris Mason
2020-10-26 15:18         ` Vincent Guittot
2020-10-26 15:28         ` Chris Mason [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E3EBECF9-D16E-4D5B-B4F7-675B42624F19@fb.com \
    --to=clm@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@surriel.com \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).