From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 08F5E2FE595; Thu, 19 Feb 2026 14:19:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771510777; cv=none; b=oJUijJlL2P0VgyXj3GyNRSaNkx4bywdiXMZNbUU7Tr19Y6/kSsHw5r+TpZQ5T2cRuXZfuS9yKam9vbda5y9wUfEd/OYM/Mz6tY8wL14D/bxiJGTMF+47mW6xmgLe21puRp+68WYUn34tRK4c533ByBFimSMDwWY3Vi+nHpD39uM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771510777; c=relaxed/simple; bh=WZxPjuvtJUEZN+0yhSYnrlafptb0X+sYlOujxHYfplU=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=SAXb6UTzdsHF2+aUEAuMI9MBRRkwlDBIWMRh2fo+r1QLyUbJFCksKpLpMbfr8B9X3pEDPvJ6hDMfiQd2cGIHUhkThFAugNAFFaooBcbpkwneMPs4sDnIOnrEIS3V4tH77xiv3AqNaeoK+kJ8B/LuHYAOlDjD/YeonsHBo1OP/mk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=185.176.79.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.18.224.83]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4fGwVG3kLfzHnGj5; Thu, 19 Feb 2026 22:19:02 +0800 (CST) Received: from dubpeml500005.china.huawei.com (unknown [7.214.145.207]) by mail.maildlp.com (Postfix) with ESMTPS id B24FA40086; Thu, 19 Feb 2026 22:19:32 +0800 (CST) Received: from localhost (10.203.177.15) by dubpeml500005.china.huawei.com (7.214.145.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 19 Feb 2026 14:19:32 +0000 Date: Thu, 19 Feb 2026 14:19:30 +0000 From: Jonathan Cameron To: Gregory Price CC: Andrew Morton , Cui Chao , , Mike Rapoport , Wang Yinfeng , , , , , "David Hildenbrand (Arm)" Subject: Re: [PATCH v2 1/1] mm: numa_memblks: Identify the accurate NUMA ID of CFMW Message-ID: <20260219141930.0000124a@huawei.com> In-Reply-To: References: <2d1e23ad-7ec1-483b-88b3-70ce19b69106@phytium.com.cn> <20260205145842.efb90572a902ae4c481e6ef6@linux-foundation.org> <20260206110305.00001fbb@huawei.com> <20260206150941.000028ae@huawei.com> <20260206162644.000050fe@huawei.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) Precedence: bulk X-Mailing-List: linux-cxl@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: lhrpeml100012.china.huawei.com (7.191.174.184) To dubpeml500005.china.huawei.com (7.214.145.207) On Fri, 6 Feb 2026 11:32:09 -0500 Gregory Price wrote: > On Fri, Feb 06, 2026 at 04:26:44PM +0000, Jonathan Cameron wrote: > > > > > > This should fall out cleanly. > > > > > > The additional nodes won't be associated with anything, but could be > > > used for hotplug - I imagine. > > > > > > > That aligns with what I was thinking as a first solution to allowing this > > to be more dynamic. We can get clever later if this doesn't prove sufficient. > > > > I can get this out pretty quickly, hopefully sometime next week. > > I had a long talk with Dan about this topic previously, and I'm not sure > how we get more dynamic than this to be honest. nr_possible_nodes is > *definitely* expected to be immutable after __init all over the kernel, > it's used to allocate a memory. Indeed. But that doesn't mean to say they are all in use after __init. You end up allocating a bunch of space, that is not used until there is some memory there. Not a problem. So dynamic nr_possible_nodes is tricky. Dynamic allocation of stuff into those nodes is fine. That happens with memory hotplug today. J > > Surface area is very large here. > > ~Gregory From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 787BEE9A04C for ; Thu, 19 Feb 2026 14:20:32 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1vt4ss-0003TU-BT; Thu, 19 Feb 2026 09:20:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1vt4sl-0003SK-Od for qemu-devel@nongnu.org; Thu, 19 Feb 2026 09:19:56 -0500 Received: from frasgout.his.huawei.com ([185.176.79.56]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1vt4sg-0007Jd-Eo for qemu-devel@nongnu.org; Thu, 19 Feb 2026 09:19:55 -0500 Received: from mail.maildlp.com (unknown [172.18.224.83]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4fGwVG3kLfzHnGj5; Thu, 19 Feb 2026 22:19:02 +0800 (CST) Received: from dubpeml500005.china.huawei.com (unknown [7.214.145.207]) by mail.maildlp.com (Postfix) with ESMTPS id B24FA40086; Thu, 19 Feb 2026 22:19:32 +0800 (CST) Received: from localhost (10.203.177.15) by dubpeml500005.china.huawei.com (7.214.145.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 19 Feb 2026 14:19:32 +0000 Date: Thu, 19 Feb 2026 14:19:30 +0000 To: Gregory Price CC: Andrew Morton , Cui Chao , , Mike Rapoport , Wang Yinfeng , , , , , "David Hildenbrand (Arm)" Subject: Re: [PATCH v2 1/1] mm: numa_memblks: Identify the accurate NUMA ID of CFMW Message-ID: <20260219141930.0000124a@huawei.com> In-Reply-To: References: <2d1e23ad-7ec1-483b-88b3-70ce19b69106@phytium.com.cn> <20260205145842.efb90572a902ae4c481e6ef6@linux-foundation.org> <20260206110305.00001fbb@huawei.com> <20260206150941.000028ae@huawei.com> <20260206162644.000050fe@huawei.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.203.177.15] X-ClientProxiedBy: lhrpeml100012.china.huawei.com (7.191.174.184) To dubpeml500005.china.huawei.com (7.214.145.207) Received-SPF: pass client-ip=185.176.79.56; envelope-from=jonathan.cameron@huawei.com; helo=frasgout.his.huawei.com X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Jonathan Cameron From: Jonathan Cameron via qemu development Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On Fri, 6 Feb 2026 11:32:09 -0500 Gregory Price wrote: > On Fri, Feb 06, 2026 at 04:26:44PM +0000, Jonathan Cameron wrote: > > > > > > This should fall out cleanly. > > > > > > The additional nodes won't be associated with anything, but could be > > > used for hotplug - I imagine. > > > > > > > That aligns with what I was thinking as a first solution to allowing this > > to be more dynamic. We can get clever later if this doesn't prove sufficient. > > > > I can get this out pretty quickly, hopefully sometime next week. > > I had a long talk with Dan about this topic previously, and I'm not sure > how we get more dynamic than this to be honest. nr_possible_nodes is > *definitely* expected to be immutable after __init all over the kernel, > it's used to allocate a memory. Indeed. But that doesn't mean to say they are all in use after __init. You end up allocating a bunch of space, that is not used until there is some memory there. Not a problem. So dynamic nr_possible_nodes is tricky. Dynamic allocation of stuff into those nodes is fine. That happens with memory hotplug today. J > > Surface area is very large here. > > ~Gregory