linux-kernel - Re: [PATCH] fix scheduler regression from "sched/fair: Rework load

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <E3EBECF9-D16E-4D5B-B4F7-675B42624F19@fb.com>
Date:   Mon, 26 Oct 2020 11:28:43 -0400
From:   "Chris Mason" <clm@...com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
CC:     Peter Zijlstra <peterz@...radead.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Rik van Riel <riel@...riel.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] fix scheduler regression from "sched/fair: Rework
 load_balance()"

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