Message ID | 67261c513706241d479b8b4cf46eb4e6fb0417ba.1679387262.git.geert+renesas@glider.be |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp1660102wrt; Tue, 21 Mar 2023 01:43:28 -0700 (PDT) X-Google-Smtp-Source: AK7set+gR08THBxwTcOJYiXbzXcOrmSFy9pr8OLRr3AnW240qdUoKE0AyAXEJHtkWdqluxIu8+s6 X-Received: by 2002:a17:90b:50d:b0:237:ae98:a47f with SMTP id r13-20020a17090b050d00b00237ae98a47fmr1460051pjz.1.1679388208435; Tue, 21 Mar 2023 01:43:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679388208; cv=none; d=google.com; s=arc-20160816; b=rJs9D5zC7rC5B4qZBZ0Lc3XtxE++/F+roBhesKnhVEQxeBXSfRmIHIf9ZRzdTUoVXZ jxwVx2gzgpBhXEAV59lQi6Vkq/u4hlFdez7r4i70L1Rxif7fZ6nnI+rpyo1+EKNvQGuw rP6K4bmJI3ZBmx6myOoftcFmEo7+uP/PiRezmchTOWVVf9FKJzzSLDFb1Cpon5mgVNy9 wIgTUz9TbVKRnfPlOXD0iLyKqTdbOKXx9huOGWOsg0rIHjyVKiZbwPAs3gQ7ni8P6kBW YFJgYqXJ52vrR0o0Sb1VCBTiPio0lw0B3/1SabJ8OMaL/77EWS7Cjn4/bilb5rQ8jHlb 1GoA== 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=JU2KGO7hMIMmKn7/4GppMdGXO2OELXN8RzbIXO4KOGY=; b=MBzNojAU6sy0L9UDIjrQtXgseF1TsQh+fYIG2NEFgivaDrbp17YzSPAjQ4p+4Is6je AL99aMeSZinkU2p5rW7Ptx4rXMX5A4tnb14gU0FV9pHVhhMXMVEjM+FBnG0QgrzV7dEb QnOVfSjbMAogEb+FCpAFZtq7K8kCJWHXRQ/saowp3+wfryjypd6NJsfG25L2UTGEjLs2 xpOK84YNP13zH7prgibhy+N+33rlHCDgikpHOEPhxbBKnNd+dtU8a3vK4smUwo7tt/DT HKMv6Kpg3ixO9rP/s0h8U50mW+eCpUAR5vun08wDOQUrPfLmWRDCnQvK3F4C/uKMyLZ/ EP/A== 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mi7-20020a17090b4b4700b0023f692a5033si11685926pjb.135.2023.03.21.01.43.13; Tue, 21 Mar 2023 01:43:28 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229768AbjCUIcW (ORCPT <rfc822;pusanteemu@gmail.com> + 99 others); Tue, 21 Mar 2023 04:32:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229791AbjCUIcH (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 21 Mar 2023 04:32:07 -0400 Received: from michel.telenet-ops.be (michel.telenet-ops.be [IPv6:2a02:1800:110:4::f00:18]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1BBDF6A73 for <linux-kernel@vger.kernel.org>; Tue, 21 Mar 2023 01:31:10 -0700 (PDT) Received: from ramsan.of.borg ([84.195.187.55]) by michel.telenet-ops.be with bizsmtp id awX12900E1C8whw06wX1Zd; Tue, 21 Mar 2023 09:31:08 +0100 Received: from rox.of.borg ([192.168.97.57]) by ramsan.of.borg with esmtp (Exim 4.95) (envelope-from <geert@linux-m68k.org>) id 1peXNr-00E6VQ-Gp; Tue, 21 Mar 2023 09:31:01 +0100 Received: from geert by rox.of.borg with local (Exim 4.95) (envelope-from <geert@linux-m68k.org>) id 1peXOX-007g6A-62; Tue, 21 Mar 2023 09:31:01 +0100 From: Geert Uytterhoeven <geert+renesas@glider.be> To: Dave Hansen <dave.hansen@linux.intel.com>, Arnd Bergmann <arnd@arndb.de>, Christoph Lameter <cl@linux.com>, Pekka Enberg <penberg@kernel.org>, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Andrew Morton <akpm@linux-foundation.org>, Vlastimil Babka <vbabka@suse.cz>, Roman Gushchin <roman.gushchin@linux.dev>, Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>, linux-mm@kvack.org, linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org, Geert Uytterhoeven <geert+renesas@glider.be>, Randy Dunlap <rdunlap@infradead.org> Subject: [PATCH] mm/slab: Fix undefined init_cache_node_node() for NUMA and !SMP Date: Tue, 21 Mar 2023 09:30:59 +0100 Message-Id: <67261c513706241d479b8b4cf46eb4e6fb0417ba.1679387262.git.geert+renesas@glider.be> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE autolearn=unavailable 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?1760966170142553374?= X-GMAIL-MSGID: =?utf-8?q?1760966170142553374?= |
Series |
mm/slab: Fix undefined init_cache_node_node() for NUMA and !SMP
|
|
Commit Message
Geert Uytterhoeven
March 21, 2023, 8:30 a.m. UTC
sh/migor_defconfig:
mm/slab.c: In function ‘slab_memory_callback’:
mm/slab.c:1127:23: error: implicit declaration of function ‘init_cache_node_node’; did you mean ‘drain_cache_node_node’? [-Werror=implicit-function-declaration]
1127 | ret = init_cache_node_node(nid);
| ^~~~~~~~~~~~~~~~~~~~
| drain_cache_node_node
The #ifdef condition protecting the definition of init_cache_node_node()
no longer matches the conditions protecting the (multiple) users.
Fix this by syncing the conditions.
Fixes: 76af6a054da40553 ("mm/migrate: add CPU hotplug to demotion #ifdef")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/b5bdea22-ed2f-3187-6efe-0c72330270a4@infradead.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
mm/slab.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Hi Geert! On Tue, 2023-03-21 at 09:30 +0100, Geert Uytterhoeven wrote: > sh/migor_defconfig: > > mm/slab.c: In function ‘slab_memory_callback’: > mm/slab.c:1127:23: error: implicit declaration of function ‘init_cache_node_node’; did you mean ‘drain_cache_node_node’? [-Werror=implicit-function-declaration] > 1127 | ret = init_cache_node_node(nid); > | ^~~~~~~~~~~~~~~~~~~~ > | drain_cache_node_node > > The #ifdef condition protecting the definition of init_cache_node_node() > no longer matches the conditions protecting the (multiple) users. > > Fix this by syncing the conditions. > > Fixes: 76af6a054da40553 ("mm/migrate: add CPU hotplug to demotion #ifdef") > Reported-by: Randy Dunlap <rdunlap@infradead.org> > Link: https://lore.kernel.org/r/b5bdea22-ed2f-3187-6efe-0c72330270a4@infradead.org > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > --- > mm/slab.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/slab.c b/mm/slab.c > index ba454246ee13dd4d..de1523a78f2e7367 100644 > --- a/mm/slab.c > +++ b/mm/slab.c > @@ -839,7 +839,7 @@ static int init_cache_node(struct kmem_cache *cachep, int node, gfp_t gfp) > return 0; > } > > -#if (defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)) || defined(CONFIG_SMP) > +#if defined(CONFIG_NUMA) || defined(CONFIG_SMP) > /* > * Allocates and initializes node for a node on each slab cache, used for > * either memory or cpu hotplug. If memory is being hot-added, the kmem_cache_node FWIW, the other #ifdef starting at drain_cache_node_node() closes with "#endif /* CONFIG_NUMA */", while this #ifdef just ends with "#endif". Just in case you want to make this consistent. Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Adrian
Hi Adrian, On Tue, Mar 21, 2023 at 9:47 AM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: > On Tue, 2023-03-21 at 09:30 +0100, Geert Uytterhoeven wrote: > > sh/migor_defconfig: > > > > mm/slab.c: In function ‘slab_memory_callback’: > > mm/slab.c:1127:23: error: implicit declaration of function ‘init_cache_node_node’; did you mean ‘drain_cache_node_node’? [-Werror=implicit-function-declaration] > > 1127 | ret = init_cache_node_node(nid); > > | ^~~~~~~~~~~~~~~~~~~~ > > | drain_cache_node_node > > > > The #ifdef condition protecting the definition of init_cache_node_node() > > no longer matches the conditions protecting the (multiple) users. > > > > Fix this by syncing the conditions. > > > > Fixes: 76af6a054da40553 ("mm/migrate: add CPU hotplug to demotion #ifdef") > > Reported-by: Randy Dunlap <rdunlap@infradead.org> > > Link: https://lore.kernel.org/r/b5bdea22-ed2f-3187-6efe-0c72330270a4@infradead.org > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > > --- > > mm/slab.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/slab.c b/mm/slab.c > > index ba454246ee13dd4d..de1523a78f2e7367 100644 > > --- a/mm/slab.c > > +++ b/mm/slab.c > > @@ -839,7 +839,7 @@ static int init_cache_node(struct kmem_cache *cachep, int node, gfp_t gfp) > > return 0; > > } > > > > -#if (defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)) || defined(CONFIG_SMP) > > +#if defined(CONFIG_NUMA) || defined(CONFIG_SMP) > > /* > > * Allocates and initializes node for a node on each slab cache, used for > > * either memory or cpu hotplug. If memory is being hot-added, the kmem_cache_node > > FWIW, the other #ifdef starting at drain_cache_node_node() closes with "#endif /* CONFIG_NUMA */", > while this #ifdef just ends with "#endif". Just in case you want to make this consistent. I guess that's fine, as init_cache_node_node() is a small function. #endif comments are typically used when the start and end markers do not fit on your (80x25 ;-) screen. > Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Thanks! Gr{oetje,eeting}s, Geert
On 3/21/23 09:50, Geert Uytterhoeven wrote: > Hi Adrian, > > On Tue, Mar 21, 2023 at 9:47 AM John Paul Adrian Glaubitz > <glaubitz@physik.fu-berlin.de> wrote: >> On Tue, 2023-03-21 at 09:30 +0100, Geert Uytterhoeven wrote: >> > sh/migor_defconfig: >> > >> > mm/slab.c: In function ‘slab_memory_callback’: >> > mm/slab.c:1127:23: error: implicit declaration of function ‘init_cache_node_node’; did you mean ‘drain_cache_node_node’? [-Werror=implicit-function-declaration] >> > 1127 | ret = init_cache_node_node(nid); >> > | ^~~~~~~~~~~~~~~~~~~~ >> > | drain_cache_node_node >> > >> > The #ifdef condition protecting the definition of init_cache_node_node() >> > no longer matches the conditions protecting the (multiple) users. >> > >> > Fix this by syncing the conditions. >> > >> > Fixes: 76af6a054da40553 ("mm/migrate: add CPU hotplug to demotion #ifdef") >> > Reported-by: Randy Dunlap <rdunlap@infradead.org> >> > Link: https://lore.kernel.org/r/b5bdea22-ed2f-3187-6efe-0c72330270a4@infradead.org >> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> >> > --- >> > mm/slab.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/mm/slab.c b/mm/slab.c >> > index ba454246ee13dd4d..de1523a78f2e7367 100644 >> > --- a/mm/slab.c >> > +++ b/mm/slab.c >> > @@ -839,7 +839,7 @@ static int init_cache_node(struct kmem_cache *cachep, int node, gfp_t gfp) >> > return 0; >> > } >> > >> > -#if (defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)) || defined(CONFIG_SMP) >> > +#if defined(CONFIG_NUMA) || defined(CONFIG_SMP) >> > /* >> > * Allocates and initializes node for a node on each slab cache, used for >> > * either memory or cpu hotplug. If memory is being hot-added, the kmem_cache_node >> >> FWIW, the other #ifdef starting at drain_cache_node_node() closes with "#endif /* CONFIG_NUMA */", >> while this #ifdef just ends with "#endif". Just in case you want to make this consistent. > > I guess that's fine, as init_cache_node_node() is a small function. > #endif comments are typically used when the start and end markers > do not fit on your (80x25 ;-) screen. Agreed with this reasoning. >> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> > > Thanks! Applied to slab/for-6.3-rc4/fixes, thanks! > Gr{oetje,eeting}s, > > Geert >
On 3/21/23 01:30, Geert Uytterhoeven wrote: > sh/migor_defconfig: > > mm/slab.c: In function ‘slab_memory_callback’: > mm/slab.c:1127:23: error: implicit declaration of function ‘init_cache_node_node’; did you mean ‘drain_cache_node_node’? [-Werror=implicit-function-declaration] > 1127 | ret = init_cache_node_node(nid); > | ^~~~~~~~~~~~~~~~~~~~ > | drain_cache_node_node > > The #ifdef condition protecting the definition of init_cache_node_node() > no longer matches the conditions protecting the (multiple) users. > > Fix this by syncing the conditions. > > Fixes: 76af6a054da40553 ("mm/migrate: add CPU hotplug to demotion #ifdef") > Reported-by: Randy Dunlap <rdunlap@infradead.org> > Link: https://lore.kernel.org/r/b5bdea22-ed2f-3187-6efe-0c72330270a4@infradead.org > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Randy Dunlap <rdunlap@infradead.org> Thanks. > --- > mm/slab.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/slab.c b/mm/slab.c > index ba454246ee13dd4d..de1523a78f2e7367 100644 > --- a/mm/slab.c > +++ b/mm/slab.c > @@ -839,7 +839,7 @@ static int init_cache_node(struct kmem_cache *cachep, int node, gfp_t gfp) > return 0; > } > > -#if (defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)) || defined(CONFIG_SMP) > +#if defined(CONFIG_NUMA) || defined(CONFIG_SMP) > /* > * Allocates and initializes node for a node on each slab cache, used for > * either memory or cpu hotplug. If memory is being hot-added, the kmem_cache_node
On Tue, Mar 21, 2023 at 09:30:59AM +0100, Geert Uytterhoeven wrote: > -#if (defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)) || defined(CONFIG_SMP) > +#if defined(CONFIG_NUMA) || defined(CONFIG_SMP) I'm amused by the thought of CONFIG_NUMA without CONFIG_SMP. Is it possible to have one node with memory and a single CPU, then another node with memory and no CPU?
On 3/21/23 09:40, Matthew Wilcox wrote: > On Tue, Mar 21, 2023 at 09:30:59AM +0100, Geert Uytterhoeven wrote: >> -#if (defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)) || defined(CONFIG_SMP) >> +#if defined(CONFIG_NUMA) || defined(CONFIG_SMP) > > I'm amused by the thought of CONFIG_NUMA without CONFIG_SMP. > Is it possible to have one node with memory and a single CPU, then > another node with memory and no CPU? More likely 1 with CPU+memory, 1 with memory only. I've been told that that are also I/O-only nodes.
On 3/21/23 09:40, Matthew Wilcox wrote: > On Tue, Mar 21, 2023 at 09:30:59AM +0100, Geert Uytterhoeven wrote: >> -#if (defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)) || defined(CONFIG_SMP) >> +#if defined(CONFIG_NUMA) || defined(CONFIG_SMP) > I'm amused by the thought of CONFIG_NUMA without CONFIG_SMP. > Is it possible to have one node with memory and a single CPU, then > another node with memory and no CPU? It's _possible_ for sure, just unlikely. The most likely place these days is probably a teensy tiny VM that just happens to have some performance-differentiated memory exposed to it for some reason. Maybe it's got a slice of slow PMEM or fast High-Bandwidth memory for whatever reason.
On Wed, Mar 22, 2023 at 09:16:55AM -0700, Dave Hansen wrote: > On 3/21/23 09:40, Matthew Wilcox wrote: > > On Tue, Mar 21, 2023 at 09:30:59AM +0100, Geert Uytterhoeven wrote: > >> -#if (defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)) || defined(CONFIG_SMP) > >> +#if defined(CONFIG_NUMA) || defined(CONFIG_SMP) > > I'm amused by the thought of CONFIG_NUMA without CONFIG_SMP. > > Is it possible to have one node with memory and a single CPU, then > > another node with memory and no CPU? > > It's _possible_ for sure, just unlikely. The most likely place these > days is probably a teensy tiny VM that just happens to have some > performance-differentiated memory exposed to it for some reason. Maybe > it's got a slice of slow PMEM or fast High-Bandwidth memory for whatever > reason. Right, you can construct such a system, but do we support the CONFIG options of NUMA enabled and SMP disabled? It seems so niche that we shouldn't be spending time testing that combination.
On 3/22/23 09:46, Matthew Wilcox wrote: > On Wed, Mar 22, 2023 at 09:16:55AM -0700, Dave Hansen wrote: >> On 3/21/23 09:40, Matthew Wilcox wrote: >>> On Tue, Mar 21, 2023 at 09:30:59AM +0100, Geert Uytterhoeven wrote: >>>> -#if (defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)) || defined(CONFIG_SMP) >>>> +#if defined(CONFIG_NUMA) || defined(CONFIG_SMP) >>> I'm amused by the thought of CONFIG_NUMA without CONFIG_SMP. >>> Is it possible to have one node with memory and a single CPU, then >>> another node with memory and no CPU? >> It's _possible_ for sure, just unlikely. The most likely place these >> days is probably a teensy tiny VM that just happens to have some >> performance-differentiated memory exposed to it for some reason. Maybe >> it's got a slice of slow PMEM or fast High-Bandwidth memory for whatever >> reason. > Right, you can construct such a system, but do we support the CONFIG > options of NUMA enabled and SMP disabled? It seems so niche that we > shouldn't be spending time testing that combination. On x86 we don't: > config NUMA > bool "NUMA Memory Allocation and Scheduler Support" > depends on SMP > depends on X86_64 || (X86_32 && HIGHMEM64G && X86_BIGSMP) ... which I think is fine. I totally agree that NUMA without SMP is too niche to care about. Heck, !SMP is almost too niche to care about these days.
Hi Matthew, On Wed, Mar 22, 2023 at 5:47 PM Matthew Wilcox <willy@infradead.org> wrote: > On Wed, Mar 22, 2023 at 09:16:55AM -0700, Dave Hansen wrote: > > On 3/21/23 09:40, Matthew Wilcox wrote: > > > On Tue, Mar 21, 2023 at 09:30:59AM +0100, Geert Uytterhoeven wrote: > > >> -#if (defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)) || defined(CONFIG_SMP) > > >> +#if defined(CONFIG_NUMA) || defined(CONFIG_SMP) > > > I'm amused by the thought of CONFIG_NUMA without CONFIG_SMP. > > > Is it possible to have one node with memory and a single CPU, then > > > another node with memory and no CPU? > > > > It's _possible_ for sure, just unlikely. The most likely place these > > days is probably a teensy tiny VM that just happens to have some > > performance-differentiated memory exposed to it for some reason. Maybe > > it's got a slice of slow PMEM or fast High-Bandwidth memory for whatever > > reason. > > Right, you can construct such a system, but do we support the CONFIG > options of NUMA enabled and SMP disabled? It seems so niche that we > shouldn't be spending time testing that combination. SH has been using this for a long time. It's supported. Dave just forgot to update the #ifdef around the definition of init_cache_node_node() when updating an #ifdef around a code block that contains one of the callers. P.S. To me, this discussion reminds me of the old discussion about discontigmem without NUMA. Yes, not all systems are PCs with contiguous memory on a single fast bus ;-) Gr{oetje,eeting}s, Geert
Hi Geert! On Thu, 2023-03-23 at 09:25 +0100, Geert Uytterhoeven wrote: > It's supported. Dave just forgot to update the #ifdef around the > definition of init_cache_node_node() when updating an #ifdef around > a code block that contains one of the callers. > > P.S. To me, this discussion reminds me of the old discussion about > discontigmem without NUMA. Yes, not all systems are PCs with > contiguous memory on a single fast bus ;-) I'm wondering: Could the NUMA code be used to work with the different memory types found on the Amiga, i.e. chip RAM, fast RAM etc? Adrian
Hi Adrian, On Thu, Mar 23, 2023 at 9:28 AM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: > On Thu, 2023-03-23 at 09:25 +0100, Geert Uytterhoeven wrote: > > It's supported. Dave just forgot to update the #ifdef around the > > definition of init_cache_node_node() when updating an #ifdef around > > a code block that contains one of the callers. > > > > P.S. To me, this discussion reminds me of the old discussion about > > discontigmem without NUMA. Yes, not all systems are PCs with > > contiguous memory on a single fast bus ;-) > > I'm wondering: Could the NUMA code be used to work with the different > memory types found on the Amiga, i.e. chip RAM, fast RAM etc? I guess so, but only for 32-bit motherboard RAM on A3000/A4000 vs. RAM on an accelerator card vs. Zorro-III RAM on e.g. BigRamPlus. Chip RAM and Zorro-II RAM do not support RMW-cycles on Zorro-III capable machines. Gr{oetje,eeting}s, Geert
diff --git a/mm/slab.c b/mm/slab.c index ba454246ee13dd4d..de1523a78f2e7367 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -839,7 +839,7 @@ static int init_cache_node(struct kmem_cache *cachep, int node, gfp_t gfp) return 0; } -#if (defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)) || defined(CONFIG_SMP) +#if defined(CONFIG_NUMA) || defined(CONFIG_SMP) /* * Allocates and initializes node for a node on each slab cache, used for * either memory or cpu hotplug. If memory is being hot-added, the kmem_cache_node