Received: by 2002:a05:6a10:87d6:0:0:0:0 with SMTP id g22csp9592pxr; Sun, 10 Apr 2022 05:15:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzAsyA6zebuAjQi2HRyT7xO8mFIdkvBJjZSvXYT7muuXEDDhXCKbHJF9x60W5e5AHsz5IBE X-Received: by 2002:a17:907:3da9:b0:6db:f3f:33c2 with SMTP id he41-20020a1709073da900b006db0f3f33c2mr25367561ejc.735.1649592934667; Sun, 10 Apr 2022 05:15:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649592934; cv=none; d=google.com; s=arc-20160816; b=dDpdS3hSVvKKW/4RPm2baBCxXlEND2YjcUI5kC8sXwsL7L+M9YDxtMZnhJ2T65Vbwq I45UFLux6ffp1iX9e/0UIQuxwbJRzOseTRcj02hs5JKm8Kz/jrbtfrxRnrkxFf1hE+rx /p22Ec3ykl8UOKCdH6Qjub4HmTOMuF3WcMZjU/0Ot97ibEa4kUc52L6CMnUHVqKAXK4h KyjqsnMe0g6K9L/NFIIl0Y9OIFTy1kU0y3mdBv/Vg18bWWoazc9y8hMFDJcsJslfsgTc L+bOZqWtBWSJZKpth0NEfDfxRzDiElM/IrY8grYxjoeP+HJ+lIbuvufSvZvtMolsJfRS V/8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:to:from:dkim-signature; bh=re0SYElh8Djw9DjBeyMp4tYzK4WKuGI/dfR89zOFSkU=; b=pn6mw/wWGNxFcka9bWQc0F5jv8bZgJzJXqe8ewWLSD5hbIPatM5jgafiJMksK9Ykne vdVhb0Vi11gev8i3YQoEkQAAYoX8GvqzcR8yBFyIBOEIQems1E/xDgeqGULCO7gyIlHf cRBWQkje3qiGafkjtQOXgUGrYXXDHCnrX7rHTkamq8kxKgCq55XNroPRkcojKDey8+1l /6vbo8Fuix36akLkKDuWLA3YdXe/Zpf1Qf3uAboNOOAQGhamE75ZDUlbruxTxedfUTNq VQlF+Y1qZHMTrBzOs9dfe78SHtKBwEX92X+4y3Ir86KPsPvNixyT8iJapA4rRnc10o6O kDaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=NtOy2QtB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id tj6-20020a170907c24600b006e7f5ad72d2si4488019ejc.601.2022.04.10.05.14.30; Sun, 10 Apr 2022 05:15:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=NtOy2QtB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232296AbiDJFAz (ORCPT + 99 others); Sun, 10 Apr 2022 01:00:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229590AbiDJFAv (ORCPT ); Sun, 10 Apr 2022 01:00:51 -0400 Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A1C01BE for ; Sat, 9 Apr 2022 21:58:41 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id mm4-20020a17090b358400b001cb93d8b137so11945pjb.2 for ; Sat, 09 Apr 2022 21:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:date:message-id; bh=re0SYElh8Djw9DjBeyMp4tYzK4WKuGI/dfR89zOFSkU=; b=NtOy2QtB5ZZ5MdRiOw8B29TeCsbwI6UVuJx9uJafnW0wQxaovIcUYo+kuYx0CDvz7H HuoXtb7jzixpLB/BcijksoITt6TTd+KY1BQuxP4Y3H5xXQPA7KYotiuy7IxmSKkwDvYH +MQ1HppNI2wNmSp75BesS5P6t6iV4f3puka8iXmCYhig88cd5HxvHQ1rrnsp/RDGLy60 NBoBxf3eyB9/FG7Ub8h0tpX24ksxv20SmSfI0tPX1VIND9f+C9sf6+hJt45OH0x2KRzc yYFukm3xRYI1QCVNRJiNbzwegJYkT/YK7S266vfQntxas9Kv0h9XZn2GwUxmCncnJk4q wiBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id; bh=re0SYElh8Djw9DjBeyMp4tYzK4WKuGI/dfR89zOFSkU=; b=kJ8L3/nQJsBX7M/dQPrOWrXFZRvxFrtd3y31VI6fKfjrutDVdXQIlO0B+wF7963rBN UuqMfFcq3Xo3iUuph1HRnCqCqiX2TLFs/Kr0XnVnI4lDIiNLxgHNClXrNFWcTFNz+yrN 3rVUS6kw5j+PyX5ykhcaJAOIfLDcBwl2tUUIADHufc9+krre/wK0/173cCBzxCnzLF1s h8/E+W68yCAXzaWqpzSV/iZGfoAuBgHl2LXFzOkHlBIorcHGLTaYg7OzSKUjBgnToiRI kOhFCUy/OU7vRACQR9qb//VDzPUv3MMUpJi+ploBt4Q+TZzkySZPzvO5Eva608y+INkr 6LxQ== X-Gm-Message-State: AOAM531aZBZNMqonadx/sT6KzzDypIzrWPZjCUurKuHRERYNjjLNa2/n mlJtg9MEwVg24TM1C0TfuOw= X-Received: by 2002:a17:902:ced0:b0:153:f78e:c43f with SMTP id d16-20020a170902ced000b00153f78ec43fmr26374284plg.64.1649566721041; Sat, 09 Apr 2022 21:58:41 -0700 (PDT) Received: from localhost.localdomain ([150.109.127.35]) by smtp.gmail.com with ESMTPSA id y2-20020a056a00190200b004fa865d1fd3sm30493643pfi.86.2022.04.09.21.58.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Apr 2022 21:58:40 -0700 (PDT) From: zgpeng X-Google-Original-From: zgpeng To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, linux-kernel@vger.kernel.org Subject: [PATCH] sched/fair: Fix the scene where group's imbalance is set incorrectly Date: Sun, 10 Apr 2022 12:58:36 +0800 Message-Id: <1649566716-24687-1-git-send-email-zgpeng@tencent.com> X-Mailer: git-send-email 2.7.4 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In the load_balance function, if the balance fails due to affinity,then parent group's imbalance will be set to 1. However, there will be a scene where balance is achieved, but the imbalance flag is still set to 1, which needs to be fixed. The specific trigger scenarios are as follows. In the load_balance function, the first loop picks out the busiest cpu. During the process of pulling the process from the busiest cpu, it is found that all tasks cannot be run on the DST cpu. At this time, both LBF_SOME_PINNED andLBF_ALL_PINNED of env.flags are set. Because balance fails and LBF_SOME_PINNED is set, the parent group's mbalance flag will be set to 1. At the same time, because LBF_ALL_PINNED is set, it will re-enter the second cycle to select another busiest cpu to pull the process. Because the busiest CPU has changed, the process can be pulled to DST cpu, so it is possible to reach a balance state. But at this time, the parent group's imbalance flag is not set correctly again. As a result, the load balance is successfully achieved, but the parent group's imbalance flag is incorrectly set to 1. In this case, the upper-layer load balance will erroneously select this domain as the busiest group, thereby breaking the balance. Signed-off-by: zgpeng --- kernel/sched/fair.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index d4bd299..e137917 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -10019,13 +10019,13 @@ static int load_balance(int this_cpu, struct rq *this_rq, } /* - * We failed to reach balance because of affinity. + * According to balance status, set group_imbalance correctly. */ if (sd_parent) { int *group_imbalance = &sd_parent->groups->sgc->imbalance; - if ((env.flags & LBF_SOME_PINNED) && env.imbalance > 0) - *group_imbalance = 1; + if (env.flags & LBF_SOME_PINNED) + *group_imbalance = env.imbalance > 0 ? 1 : 0; } /* All tasks on this runqueue were pinned by CPU affinity */ -- 2.9.5