Message ID | 20230530082507.10444-1-yangyicong@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp2028215vqr; Tue, 30 May 2023 01:43:32 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7nV3wfdWbajSax9+eFzDMhtBO8B5oKfrFz49malRUZMXsMngvSo5HjIxyVj59OScKBzPtm X-Received: by 2002:a17:903:187:b0:1a6:83fa:b370 with SMTP id z7-20020a170903018700b001a683fab370mr1884972plg.2.1685436212473; Tue, 30 May 2023 01:43:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685436212; cv=none; d=google.com; s=arc-20160816; b=hsgXYwz9Je3Ivcuez4tZJ+jKtTNt4V0Hkum1f3ofH0lS5aAIfVcLL68G4BkLCyOs51 I8qdTfpG4r6xluTU2gojNh17g305CVE1KYC/okUUW64ALiFdER+ZKxLrAUN2+IdVZaha uI2k0rfYrjwdmeDRsdvbYuWAXjVWctP+09/lPqusN/5kQoAUqFGMN2Hay52WkLJWZP2T h7adSjsJGipPuj4aEtnQSiMKQAzaGSnTSICkMffJLYV3R1VokxglwvpubMwt1oo8Kjxr gt4UoD/qlbu19R431rTSkD984JhodeypkAbzNQGAeBygKjiSPleh6t5B8MzgbxsRpAIU iQ/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=MxZ5NKGOGTFIbuix2eV+YiMiB1SqO4IyOdofLS0CEeE=; b=Aj4yzPQHeZGnJmM4s7G3PXTNfKdVO4RvrUGbU3EZfXTJGwJtipQxe/PpzJHHgs0dPn 1ogdO35GT3tMJL42hqTuscK0KoAK21MODKpaSIPLbiKz79N8pbl0SqG4igZVZfXi3jb7 Y11Ffrpg/5Q7K9g/2V7UbqzWySVlRTt6ZTowcJpXBGCH84skEv/fHtJTokCztrvrXY7e i9X28q2ZtD8R5wZKPARWHw7yKhf1XT0U8zf4kjnL5ubtowWGSEnQNCr493JQysyWMW2o OglWyfpfOMar5zuiPcaA3gQiSawcOCkgvK1bvsBlt0fy+W4o/fkvYWxIU6qQW2K9KGKT t5wQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c16-20020a170903235000b001a9b9c32ab7si268604plh.624.2023.05.30.01.43.20; Tue, 30 May 2023 01:43:32 -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; 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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230262AbjE3I0i (ORCPT <rfc822;andrewvogler123@gmail.com> + 99 others); Tue, 30 May 2023 04:26:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229915AbjE3I0e (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 30 May 2023 04:26:34 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E55EFA1 for <linux-kernel@vger.kernel.org>; Tue, 30 May 2023 01:26:32 -0700 (PDT) Received: from canpemm500009.china.huawei.com (unknown [172.30.72.54]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4QVljr3zKczqTZf; Tue, 30 May 2023 16:21:52 +0800 (CST) Received: from localhost.localdomain (10.50.163.32) by canpemm500009.china.huawei.com (7.192.105.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Tue, 30 May 2023 16:26:30 +0800 From: Yicong Yang <yangyicong@huawei.com> To: <mingo@redhat.com>, <peterz@infradead.org>, <juri.lelli@redhat.com>, <vincent.guittot@linaro.org>, <dietmar.eggemann@arm.com>, <vschneid@redhat.com>, <linux-kernel@vger.kernel.org> CC: <rostedt@goodmis.org>, <bsegall@google.com>, <mgorman@suse.de>, <bristot@redhat.com>, <yu.c.chen@intel.com>, <linuxarm@huawei.com>, <prime.zeng@huawei.com>, <wangjie125@huawei.com>, <yangyicong@hisilicon.com> Subject: [PATCH v2] sched/fair: Don't balance task to its current running CPU Date: Tue, 30 May 2023 16:25:07 +0800 Message-ID: <20230530082507.10444-1-yangyicong@huawei.com> X-Mailer: git-send-email 2.31.0 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.50.163.32] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To canpemm500009.china.huawei.com (7.192.105.203) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767307962067856922?= X-GMAIL-MSGID: =?utf-8?q?1767307962067856922?= |
Series |
[v2] sched/fair: Don't balance task to its current running CPU
|
|
Commit Message
Yicong Yang
May 30, 2023, 8:25 a.m. UTC
From: Yicong Yang <yangyicong@hisilicon.com> We've run into the case that the balancer tries to balance a migration disabled task and trigger the warning in set_task_cpu() like below: ------------[ cut here ]------------ WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240 Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <...snip> CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G O 6.1.0-rc4+ #1 Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021 pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : set_task_cpu+0x188/0x240 lr : load_balance+0x5d0/0xc60 sp : ffff80000803bc70 x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040 x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001 x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78 x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000 x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530 x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001 Call trace: set_task_cpu+0x188/0x240 load_balance+0x5d0/0xc60 rebalance_domains+0x26c/0x380 _nohz_idle_balance.isra.0+0x1e0/0x370 run_rebalance_domains+0x6c/0x80 __do_softirq+0x128/0x3d8 ____do_softirq+0x18/0x24 call_on_irq_stack+0x2c/0x38 do_softirq_own_stack+0x24/0x3c __irq_exit_rcu+0xcc/0xf4 irq_exit_rcu+0x18/0x24 el1_interrupt+0x4c/0xe4 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x74/0x78 arch_cpu_idle+0x18/0x4c default_idle_call+0x58/0x194 do_idle+0x244/0x2b0 cpu_startup_entry+0x30/0x3c secondary_start_kernel+0x14c/0x190 __secondary_switched+0xb0/0xb4 ---[ end trace 0000000000000000 ]--- Further investigation shows that the warning is superfluous, the migration disabled task is just going to be migrated to its current running CPU. This is because that on load balance if the dst_cpu is not allowed by the task, we'll re-select a new_dst_cpu as a candidate. If no task can be balanced to dst_cpu we'll try to balance the task to the new_dst_cpu instead. In this case when the migration disabled task is not on CPU it only allows to run on its current CPU, load balance will select its current CPU as new_dst_cpu and later triggers the warning above. The new_dst_cpu is chosen from the env->dst_grpmask. Currently it contains CPUs in sched_group_span() and if we have overlapped groups it's possible to run into this case. This patch makes env->dst_grpmask of group_balance_mask() which exclude any CPUs from the busiest group and solve the issue. For balancing in a domain with no overlapped groups the behaviour keeps same as before. Suggested-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> --- Change since v1: - Solve the issue by making env->dst_cpumask of group_balance_mask(), per Vincent Link: https://lore.kernel.org/all/20230524072018.62204-1-yangyicong@huawei.com/ - Thanks Valentin for the knowledge of migration disable. Previous discussion can be found at https://lore.kernel.org/all/20230313065759.39698-1-yangyicong@huawei.com/ kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Tue, 30 May 2023 at 10:26, Yicong Yang <yangyicong@huawei.com> wrote: > > From: Yicong Yang <yangyicong@hisilicon.com> > > We've run into the case that the balancer tries to balance a migration > disabled task and trigger the warning in set_task_cpu() like below: > > ------------[ cut here ]------------ > WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240 > Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <...snip> > CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G O 6.1.0-rc4+ #1 > Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021 > pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > pc : set_task_cpu+0x188/0x240 > lr : load_balance+0x5d0/0xc60 > sp : ffff80000803bc70 > x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040 > x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001 > x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78 > x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000 > x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000 > x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000 > x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530 > x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e > x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a > x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001 > Call trace: > set_task_cpu+0x188/0x240 > load_balance+0x5d0/0xc60 > rebalance_domains+0x26c/0x380 > _nohz_idle_balance.isra.0+0x1e0/0x370 > run_rebalance_domains+0x6c/0x80 > __do_softirq+0x128/0x3d8 > ____do_softirq+0x18/0x24 > call_on_irq_stack+0x2c/0x38 > do_softirq_own_stack+0x24/0x3c > __irq_exit_rcu+0xcc/0xf4 > irq_exit_rcu+0x18/0x24 > el1_interrupt+0x4c/0xe4 > el1h_64_irq_handler+0x18/0x2c > el1h_64_irq+0x74/0x78 > arch_cpu_idle+0x18/0x4c > default_idle_call+0x58/0x194 > do_idle+0x244/0x2b0 > cpu_startup_entry+0x30/0x3c > secondary_start_kernel+0x14c/0x190 > __secondary_switched+0xb0/0xb4 > ---[ end trace 0000000000000000 ]--- > > Further investigation shows that the warning is superfluous, the migration > disabled task is just going to be migrated to its current running CPU. > This is because that on load balance if the dst_cpu is not allowed by the > task, we'll re-select a new_dst_cpu as a candidate. If no task can be > balanced to dst_cpu we'll try to balance the task to the new_dst_cpu > instead. In this case when the migration disabled task is not on CPU it > only allows to run on its current CPU, load balance will select its > current CPU as new_dst_cpu and later triggers the warning above. > > The new_dst_cpu is chosen from the env->dst_grpmask. Currently it > contains CPUs in sched_group_span() and if we have overlapped groups it's > possible to run into this case. This patch makes env->dst_grpmask of > group_balance_mask() which exclude any CPUs from the busiest group and > solve the issue. For balancing in a domain with no overlapped groups > the behaviour keeps same as before. > > Suggested-by: Vincent Guittot <vincent.guittot@linaro.org> > Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org> > --- > Change since v1: > - Solve the issue by making env->dst_cpumask of group_balance_mask(), per Vincent > Link: https://lore.kernel.org/all/20230524072018.62204-1-yangyicong@huawei.com/ > > - Thanks Valentin for the knowledge of migration disable. Previous discussion can > be found at > https://lore.kernel.org/all/20230313065759.39698-1-yangyicong@huawei.com/ > > kernel/sched/fair.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 373ff5f55884..0128dc9344cc 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -10744,7 +10744,7 @@ static int load_balance(int this_cpu, struct rq *this_rq, > .sd = sd, > .dst_cpu = this_cpu, > .dst_rq = this_rq, > - .dst_grpmask = sched_group_span(sd->groups), > + .dst_grpmask = group_balance_mask(sd->groups), > .idle = idle, > .loop_break = SCHED_NR_MIGRATE_BREAK, > .cpus = cpus, > -- > 2.24.0 >
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 373ff5f55884..0128dc9344cc 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -10744,7 +10744,7 @@ static int load_balance(int this_cpu, struct rq *this_rq, .sd = sd, .dst_cpu = this_cpu, .dst_rq = this_rq, - .dst_grpmask = sched_group_span(sd->groups), + .dst_grpmask = group_balance_mask(sd->groups), .idle = idle, .loop_break = SCHED_NR_MIGRATE_BREAK, .cpus = cpus,