Received: by 2002:a05:7412:37c9:b0:e2:908c:2ebd with SMTP id jz9csp2823964rdb; Fri, 22 Sep 2023 09:15:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IENPQhEV2OXXk0XZqVlPib2ZfoGUfhtqNw04Lbvv+JXWsDvSlW0IVdmIWwQcV7kECBq2D+N X-Received: by 2002:a92:d30d:0:b0:34f:36ae:e8d2 with SMTP id x13-20020a92d30d000000b0034f36aee8d2mr34237ila.3.1695399329633; Fri, 22 Sep 2023 09:15:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695399329; cv=none; d=google.com; s=arc-20160816; b=Ma9TNfRMXmqKaoVNcr3v9n5e+cFN2kDqmHogQ3LG90yDrcPD8lRkgbOOSBFsxw1VX2 jTbaLQEE60UV002BAFjuEE84LozIaqzKD3bq3XgSfUkxFKTLi2iugtjg1qNvoN6VN8XK 6qmC3h0s0LvDFE5YHg1HIR3wLw8+VDQ38nsy0U84HiQkw0iGYA2Zblbl9xSG08eC/ilg lbjBR2cdrNZOc3Dqs/Q2UQI7AsXRhenSDJcGg1oXeE2MpRqZHAFcKxdBwEW5OfEj5/17 wdnDOkmyuxaAbo2Lc7jXy4eJYTpCeBd6rULOavvJKxfojlg4EGptlYgOMkoazSC6lzYZ abeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=CL0G/yw0XWv2BFaLWozro5dI18Hg94U1n+Ayu8KNmfo=; fh=4y7EmVrf4l9TKDel38efcyVDWeQYmK868lcf3MB+ZHY=; b=I/xo3PjU/RM3uy8a1SFELSBYfkHdzTAzfvQYJVc7eXXcsOjY0XoqEJKaGLd6OTlTN2 8loUTp8gNEu3GON/NjVHtMbM8vJk6K+8cqZ3mcqEzJHVTJ33qN8hICKM4MrJDHgDy+PX XHrgnc94w7GbbzQ+yYVHHwoS3V7S7MxWZQWNxDLlYOoUYGj+pOW23fT/wV6t/98pLIC8 lWavE0OBXO8UYsiw7Mot7lWlMkbTy/wZHYK+NwvTiJshNL8lp6R1z6NVmvNj/EZwV2+f bzFFPZ6Xugj/ui/kc1jyyvClbcNgUPnS170i6Hcgyr8H72LrUiLjg2Gr3eFhoR7Js+fk c6ww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id k70-20020a638449000000b00577f6b56757si3999685pgd.495.2023.09.22.09.15.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Sep 2023 09:15:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id DA51D84DB7B6; Fri, 22 Sep 2023 08:03:47 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232123AbjIVPDv (ORCPT + 99 others); Fri, 22 Sep 2023 11:03:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232046AbjIVPDu (ORCPT ); Fri, 22 Sep 2023 11:03:50 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id DCF7DC6 for ; Fri, 22 Sep 2023 08:03:43 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CF4CDDA7; Fri, 22 Sep 2023 08:04:20 -0700 (PDT) Received: from [10.34.100.121] (e126645.nice.arm.com [10.34.100.121]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 49BD13F5A1; Fri, 22 Sep 2023 08:03:42 -0700 (PDT) Message-ID: <2a3c2cf0-44e3-befd-c7b5-d3c1fafbf2cd@arm.com> Date: Fri, 22 Sep 2023 17:03:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH] sched/fair: Skip cpus with no sched domain attached during NOHZ idle balance Content-Language: en-US To: "Zhang, Rui" , "Lu, Aaron" Cc: "tj@kernel.org" , "dietmar.eggemann@arm.com" , "peterz@infradead.org" , "linux-kernel@vger.kernel.org" , "vincent.guittot@linaro.org" , "longman@redhat.com" , "mingo@redhat.com" , "Pandruvada, Srinivas" References: <20230804090858.7605-1-rui.zhang@intel.com> <20230814031432.GA574314@ziqianlu-dell> <20230911114218.GA334545@ziqianlu-dell> <0d1c440becca151db3f3b05b3fb2c63fe69c2904.camel@intel.com> <0a0ff05cd1ef629cfa0a4c9392f499459fe814e7.camel@intel.com> From: Pierre Gondois In-Reply-To: <0a0ff05cd1ef629cfa0a4c9392f499459fe814e7.camel@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE 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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Fri, 22 Sep 2023 08:03:48 -0700 (PDT) Hi Rui, On 9/20/23 09:24, Zhang, Rui wrote: > Hi, Pierre, > > Sorry for the late response. I'm still ramping up on the related code. No worries, I also need to read the code, > > On Thu, 2023-09-14 at 16:53 +0200, Pierre Gondois wrote: >> >> >> On 9/14/23 11:23, Zhang, Rui wrote: >>> Hi, Pierre, >>> >>>> >>>> Yes right indeed, >>>> This happens when putting a CPU offline (as you mentioned >>>> earlier, >>>> putting a CPU offline clears the CPU in the idle_cpus_mask). >>>> >>>> The load balancing related variables >>> >>> including? >> >> I meant the nohz idle variables in the load balancing, so I was >> referring to: >> (struct sched_domain_shared).nr_busy_cpus >> (struct sched_domain).nohz_idle >> nohz.idle_cpus_mask >> nohz.nr_cpus >> (struct rq).nohz_tick_stopped > > IMO, the problem is that, for an isolated CPU, > 1. it is not an idle cpu (nohz.idle_cpus_mask should be cleared) > 2. it is not a busy cpu (sds->nr_busy_cpus should be decreased) > > But current code does not have a third state to describe this, so we > need to either > 1. add extra logic, like on_null_domain() checks I m not sure I understand, do you mean adding on_null_domain() in addition to the one in the present patch ? > or > 2. rely on current logic, but update all related variables correctly, > like you proposed. > > But in any case, we should stick with one direction. > > If we follow the first one, the original patch should be used, which > IMO is simple and straight forward. > If we follow the later one, we'd better audit and remove the current > on_null_domain() usage at the same time. TBH, I'm not confident enough Here aswell, I'm not sure I understand whether you are referring to the on_null_domain() call in the present patch or to the on_null_domain() calls in fair.c ? Regards, Pierre > to make such a change. But if you want to propose something, I'd glad > to test it. > > thanks, > rui >