Message ID | E1r0JLa-00CTxY-Uv@rmk-PC.armlinux.org.uk |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:aa0b:0:b0:403:3b70:6f57 with SMTP id k11csp140547vqo; Tue, 7 Nov 2023 02:31:47 -0800 (PST) X-Google-Smtp-Source: AGHT+IFxVbWGy+GVX4I1clYYENV0yacoSpCnVQU3y1PkiGfVvPjdNssCSzeSRf6BL1dIM2a38EDy X-Received: by 2002:a17:903:230b:b0:1cc:589d:e584 with SMTP id d11-20020a170903230b00b001cc589de584mr24414083plh.16.1699353106637; Tue, 07 Nov 2023 02:31:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699353106; cv=none; d=google.com; s=arc-20160816; b=JluWJ5j6RmWgzA0mTa8nRcwWfKB1PinZ8nVirKuEyQk6RdnXJ2NVglDk/xCE+MqHZD tigRg7GZCoZSIe5zvUVIXJDieEXbOUisQwPL7Pf9IctrOXHJ5aniGX5FXK0yiHLVExmd 5Byi281K/wnA9hx3RrfQ9wPDN6rGLI8GMkdZfiqhMTfS+D8xqnlwzHOPtYM7or/kPO/L QV6WVy8nZu88o2rIoLRWcPug8fB3q2z+I733ZKLcV/YBa4X2pd555GVJewZMKtLytCrZ TLVsaG1BiMGjN0J2S2EGwSOTMIIeIXlK2YO1EKpgq5s567kxna+1AnyUALBSkK66dazA wcPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:date:sender:message-id:content-transfer-encoding :content-disposition:mime-version:subject:cc:to:from:references :in-reply-to:dkim-signature; bh=B2mYLeaTLi2RKWi068dxPknxY80IYTqbrhnkvkRDiuE=; fh=vGp9XFM4D1RKi7jyAIjKAaHKfpl3Nk8bXN5xkWYvhvI=; b=Z2M2m6FNU5ue8+xcQui+m8QUTpyD6ZgygkJXOwWbjhXHpzwM3wJ57JUH73CbpMqKFP hjuTldx8vw0NvwkUVeHVnjm/jWSq6qUI0jIaAG6DBd5hf9DQ3XWKH5tXrguJUI8akVpX ABHpvEwA0FvdQAHhd3lTKPyBcMXOzBpjT9ZtcTTEzp0u9tb15fvT9gf5i9O9s7WX8Lwa eNiqRKw/pgUN/cEdarWBKRmF5MS4P5SiA2A3DRY3AavJggi0pZiX7+s3KXJPkPWmebuX pUwjH2Qh5QZ8vi5VV6JvEU/qUXjbB80ykY4t2Senn9+f+x1a8dbScsMPhYGEgOmG3ArP 0aNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=dqcnH4JH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id s12-20020a170902ea0c00b001c77674ea94si10941821plg.434.2023.11.07.02.31.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Nov 2023 02:31:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=dqcnH4JH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 035878028933; Tue, 7 Nov 2023 02:31:44 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234040AbjKGKbD (ORCPT <rfc822;lhua1029@gmail.com> + 32 others); Tue, 7 Nov 2023 05:31:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36764 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234048AbjKGKaa (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 7 Nov 2023 05:30:30 -0500 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 078C110CF; Tue, 7 Nov 2023 02:30:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Date:Sender:Message-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:Subject:Cc:To:From:References: In-Reply-To:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=B2mYLeaTLi2RKWi068dxPknxY80IYTqbrhnkvkRDiuE=; b=dqcnH4JHbhq+YyuErnnwbDz8AN 0aZHSKx0GUxYcKgXYu+ufg2cb8kYEmwx+9kFA1w4O4SyrvG+1OUdeuxsMHh2eLeLdkByAWX4X3oAz 2NO1ccm9fwHvFF2bXexmTLIQFvhf3Qz/DmRmQrmP+rcr76RnT2KsoSlxcfXP+7GCe+AP8as7RQRsh PmNfmj8Cg3tcxdNxPxdJVtZXPcRFD/Kr+zcnE867HVQbpMciT0HRPaxiHcaaDbAvZ36cCRU1uznTv t2z4hpxFimnFtmEAgZQioZfNIPtAqdcKWzGgkyzsh3sSohV2F7UJLYN38lWTMr+ZWxB3YwUcNX/qc 768F37qQ==; Received: from e0022681537dd.dyn.armlinux.org.uk ([fd8f:7570:feb6:1:222:68ff:fe15:37dd]:42208 helo=rmk-PC.armlinux.org.uk) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <rmk@armlinux.org.uk>) id 1r0JLd-0000Gy-1D; Tue, 07 Nov 2023 10:30:17 +0000 Received: from rmk by rmk-PC.armlinux.org.uk with local (Exim 4.94.2) (envelope-from <rmk@rmk-PC.armlinux.org.uk>) id 1r0JLa-00CTxY-Uv; Tue, 07 Nov 2023 10:30:15 +0000 In-Reply-To: <ZUoRY33AAHMc5ThW@shell.armlinux.org.uk> References: <ZUoRY33AAHMc5ThW@shell.armlinux.org.uk> From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> To: linux-pm@vger.kernel.org, loongarch@lists.linux.dev, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, kvmarm@lists.linux.dev, x86@kernel.org, linux-csky@vger.kernel.org, linux-doc@vger.kernel.org, linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org Cc: Salil Mehta <salil.mehta@huawei.com>, Jean-Philippe Brucker <jean-philippe@linaro.org>, jianyong.wu@arm.com, justin.he@arm.com, James Morse <james.morse@arm.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J. Wysocki" <rafael@kernel.org> Subject: [PATCH RFC 11/22] drivers: base: remove unnecessary call to register_cpu_under_node() MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Message-Id: <E1r0JLa-00CTxY-Uv@rmk-PC.armlinux.org.uk> Sender: Russell King <rmk@armlinux.org.uk> Date: Tue, 07 Nov 2023 10:30:14 +0000 X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 07 Nov 2023 02:31:44 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781900883308547706 X-GMAIL-MSGID: 1781900883308547706 |
Series |
Initial cleanups for vCPU hotplug
|
|
Commit Message
Russell King (Oracle)
Nov. 7, 2023, 10:30 a.m. UTC
Since "drivers: base: Move cpu_dev_init() after node_dev_init()", we
can remove some redundant code.
node_dev_init() will walk through the nodes calling register_one_node()
on each. This will trickle down to __register_one_node() which walks
all present CPUs, calling register_cpu_under_node() on each.
register_cpu_under_node() will call get_cpu_device(cpu) for each, which
will return NULL until the CPU is registered using register_cpu(). This
now happens _after_ node_dev_init().
Therefore, calling register_cpu_under_node() from __register_one_node()
becomes a no-op, and can be removed.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/base/node.c | 7 -------
1 file changed, 7 deletions(-)
Comments
On 11/7/23 20:30, Russell King (Oracle) wrote: > Since "drivers: base: Move cpu_dev_init() after node_dev_init()", we > can remove some redundant code. > > node_dev_init() will walk through the nodes calling register_one_node() > on each. This will trickle down to __register_one_node() which walks > all present CPUs, calling register_cpu_under_node() on each. > > register_cpu_under_node() will call get_cpu_device(cpu) for each, which > will return NULL until the CPU is registered using register_cpu(). This > now happens _after_ node_dev_init(). > > Therefore, calling register_cpu_under_node() from __register_one_node() > becomes a no-op, and can be removed. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > drivers/base/node.c | 7 ------- > 1 file changed, 7 deletions(-) > __register_one_node() can be called in memory hot add path either. In that path, a new NUMA node can be presented and becomes online. Does this become a problem after the logic of associating CPU with newly added NUMA node? Thanks, Gavin > diff --git a/drivers/base/node.c b/drivers/base/node.c > index 493d533f8375..4d5ac7cf8757 100644 > --- a/drivers/base/node.c > +++ b/drivers/base/node.c > @@ -867,7 +867,6 @@ void register_memory_blocks_under_node(int nid, unsigned long start_pfn, > int __register_one_node(int nid) > { > int error; > - int cpu; > > node_devices[nid] = kzalloc(sizeof(struct node), GFP_KERNEL); > if (!node_devices[nid]) > @@ -875,12 +874,6 @@ int __register_one_node(int nid) > > error = register_node(node_devices[nid], nid); > > - /* link cpu under this node */ > - for_each_present_cpu(cpu) { > - if (cpu_to_node(cpu) == nid) > - register_cpu_under_node(cpu, nid); > - } > - > INIT_LIST_HEAD(&node_devices[nid]->access_list); > node_init_caches(nid); >
On Mon, Nov 13, 2023 at 02:04:32PM +1000, Gavin Shan wrote: > On 11/7/23 20:30, Russell King (Oracle) wrote: > > Since "drivers: base: Move cpu_dev_init() after node_dev_init()", we > > can remove some redundant code. > > > > node_dev_init() will walk through the nodes calling register_one_node() > > on each. This will trickle down to __register_one_node() which walks > > all present CPUs, calling register_cpu_under_node() on each. > > > > register_cpu_under_node() will call get_cpu_device(cpu) for each, which > > will return NULL until the CPU is registered using register_cpu(). This > > now happens _after_ node_dev_init(). > > > > Therefore, calling register_cpu_under_node() from __register_one_node() > > becomes a no-op, and can be removed. > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > --- > > drivers/base/node.c | 7 ------- > > 1 file changed, 7 deletions(-) > > > > __register_one_node() can be called in memory hot add path either. In that path, > a new NUMA node can be presented and becomes online. Does this become a problem > after the logic of associating CPU with newly added NUMA node? I guess this is where ordering matters. As mentioned in the commit message, register_cpu_under_node() does this: if (!node_online(nid)) return 0; obj = get_cpu_device(cpu); if (!obj) return 0; get_cpu_device() will return NULL if the CPU is not possible or is out of range, or register_cpu() has not yet been called for this CPU, and register_cpu() will call register_cpu_under_node(). I guess it is possible for a CPU it be present, but the node its associated with would not be online, which means we end up with register_cpu_under_node() returning on !node_online(nid) but we've populated the CPU devices (thus get_cpu_device(cpu) would return non-NULL). Then when the numa node comes online, we do still need to call this path, so this change is incorrect. It came about trying to address Jonathan's comment for this patch: https://lore.kernel.org/r/20230913163823.7880-7-james.morse@arm.com I think my response to Jonathan is still correct - but didn't need a code change. I'm dropping this patch.
diff --git a/drivers/base/node.c b/drivers/base/node.c index 493d533f8375..4d5ac7cf8757 100644 --- a/drivers/base/node.c +++ b/drivers/base/node.c @@ -867,7 +867,6 @@ void register_memory_blocks_under_node(int nid, unsigned long start_pfn, int __register_one_node(int nid) { int error; - int cpu; node_devices[nid] = kzalloc(sizeof(struct node), GFP_KERNEL); if (!node_devices[nid]) @@ -875,12 +874,6 @@ int __register_one_node(int nid) error = register_node(node_devices[nid], nid); - /* link cpu under this node */ - for_each_present_cpu(cpu) { - if (cpu_to_node(cpu) == nid) - register_cpu_under_node(cpu, nid); - } - INIT_LIST_HEAD(&node_devices[nid]->access_list); node_init_caches(nid);