From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>

Hi,

NUMA support for SuperH was introduced a long time ago by commit
b241cb0c885e ("sh: Support for multiple nodes.")

	"... for boards with many different memory blocks that are
	 otherwise unused (SH7722/SH7785 URAM and so forth)"

In reality, this added 128K of memory on sh7722 and sh7785 and 256K on
shx3 at the expense of all the NUMA related code in the kernel.

For build of v7.0-rc7 with defconfig and the same configuration with
CONFIG_NUMA disabled, bloat-o-meter reports difference of ~76k. Disabling
CONFIG_SPARSMEM on top increases the difference to ~94k. And that's only
overhead in code and static data that does not take into the account data
structures allocated at run time.

And all this overhead has been there for nothing for almost 8 years
because since commit ac21fc2dcb40 ("sh: switch to NO_BOOTMEM")
those additional "nodes" could not be used by the core MM because the
maximal pfn for ZONE_NORMAL was cut out at the end of the normal memory.

Mike Rapoport (Microsoft) (10):
  sh: remove CONFIG_NUMA and realted configuration options
  sh: mm: remove numa.c
  sh: mm: drop allocate_pgdat()
  sh: remove setup_bootmem_node() and plat_mem_setup()
  sh: drop dead code guarded by #ifdef CONFIG_NUMA
  sh: drop include/asm/mmzone.h
  init/Kconfig: drop ARCH_WANT_NUMA_VARIABLE_LOCALITY
  sh: init: remove call the memblock_set_node()
  sh: remove SPARSEMEM related entries from Kconfig
  sh: drop include/asm/sparsemem.h

 arch/sh/Kconfig                        |  8 ----
 arch/sh/configs/migor_defconfig        |  1 -
 arch/sh/configs/sdk7786_defconfig      |  1 -
 arch/sh/configs/se7722_defconfig       |  1 -
 arch/sh/configs/shx3_defconfig         |  1 -
 arch/sh/configs/ul2_defconfig          |  1 -
 arch/sh/include/asm/mmu.h              |  2 +
 arch/sh/include/asm/mmzone.h           | 42 --------------------
 arch/sh/include/asm/setup.h            |  3 ++
 arch/sh/include/asm/sparsemem.h        | 12 ------
 arch/sh/include/asm/topology.h         | 13 -------
 arch/sh/kernel/cpu/sh4a/setup-sh7366.c |  5 ---
 arch/sh/kernel/cpu/sh4a/setup-sh7722.c |  7 ----
 arch/sh/kernel/cpu/sh4a/setup-sh7723.c |  1 -
 arch/sh/kernel/cpu/sh4a/setup-sh7724.c |  1 -
 arch/sh/kernel/cpu/sh4a/setup-sh7757.c |  5 ---
 arch/sh/kernel/cpu/sh4a/setup-sh7785.c |  7 ----
 arch/sh/kernel/cpu/sh4a/setup-sh7786.c |  5 ---
 arch/sh/kernel/cpu/sh4a/setup-shx3.c   | 18 ---------
 arch/sh/kernel/setup.c                 |  7 ----
 arch/sh/kernel/topology.c              | 12 ------
 arch/sh/kernel/vmcore_info.c           |  4 --
 arch/sh/mm/Kconfig                     | 29 --------------
 arch/sh/mm/Makefile                    |  1 -
 arch/sh/mm/init.c                      | 24 ------------
 arch/sh/mm/numa.c                      | 53 --------------------------
 arch/sh/mm/sram.c                      |  3 +-
 init/Kconfig                           |  7 ----
 28 files changed, 6 insertions(+), 268 deletions(-)
 delete mode 100644 arch/sh/include/asm/mmzone.h
 delete mode 100644 arch/sh/include/asm/sparsemem.h
 delete mode 100644 arch/sh/mm/numa.c


base-commit: 591cd656a1bf5ea94a222af5ef2ee76df029c1d2
--
2.53.0

On Mon, Apr 13, 2026, at 12:46, Mike Rapoport wrote:
>
> NUMA support for SuperH was introduced a long time ago by commit
> b241cb0c885e ("sh: Support for multiple nodes.")
>
> 	"... for boards with many different memory blocks that are
> 	 otherwise unused (SH7722/SH7785 URAM and so forth)"
>
> In reality, this added 128K of memory on sh7722 and sh7785 and 256K on
> shx3 at the expense of all the NUMA related code in the kernel.
>
> For build of v7.0-rc7 with defconfig and the same configuration with
> CONFIG_NUMA disabled, bloat-o-meter reports difference of ~76k. Disabling
> CONFIG_SPARSMEM on top increases the difference to ~94k. And that's only
> overhead in code and static data that does not take into the account data
> structures allocated at run time.
>
> And all this overhead has been there for nothing for almost 8 years
> because since commit ac21fc2dcb40 ("sh: switch to NO_BOOTMEM")
> those additional "nodes" could not be used by the core MM because the
> maximal pfn for ZONE_NORMAL was cut out at the end of the normal memory.

I had looked at it when you asked me about it last year, and I can
confirm that agree with all your findings and the resulting patches.

Whole series

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

Two very minor points:

* It looks like you left the 'config SYS_SUPPORTS_NUMA' symbol
  in Kconfig, which no longer does anything, so this should probably
  be removed in patch 9 along with the lines that select it.

* It appears that after your series, RISC-V is the only remaining
  architecture that supports NUMA in 32-bit mode, which I think
  we should not allow as a configuration, given that this would
  run into untested code and no hardware exists for it.
  Apparently commit 4f0e8eef772e ("riscv: Add numa support for
  riscv64 platform") intended this to only be for 64-bit targets
  but did not add a Kconfig dependency for CONFIG_64BIT (or
  CONFIG_SMP, which was added later).

        Arnd

(oops, missed that earlier)

On Mon, Apr 13, 2026 at 01:14:49PM +0200, Arnd Bergmann wrote:
> On Mon, Apr 13, 2026, at 12:46, Mike Rapoport wrote:
> >
> > NUMA support for SuperH was introduced a long time ago by commit
> > b241cb0c885e ("sh: Support for multiple nodes.")
> >
> > 	"... for boards with many different memory blocks that are
> > 	 otherwise unused (SH7722/SH7785 URAM and so forth)"
> >
> > In reality, this added 128K of memory on sh7722 and sh7785 and 256K on
> > shx3 at the expense of all the NUMA related code in the kernel.
> >
> > For build of v7.0-rc7 with defconfig and the same configuration with
> > CONFIG_NUMA disabled, bloat-o-meter reports difference of ~76k. Disabling
> > CONFIG_SPARSMEM on top increases the difference to ~94k. And that's only
> > overhead in code and static data that does not take into the account data
> > structures allocated at run time.
> >
> > And all this overhead has been there for nothing for almost 8 years
> > because since commit ac21fc2dcb40 ("sh: switch to NO_BOOTMEM")
> > those additional "nodes" could not be used by the core MM because the
> > maximal pfn for ZONE_NORMAL was cut out at the end of the normal memory.
> 
> I had looked at it when you asked me about it last year, and I can
> confirm that agree with all your findings and the resulting patches.
> 
> Whole series
> 
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>

Thanks!
 
> Two very minor points:
> 
> * It looks like you left the 'config SYS_SUPPORTS_NUMA' symbol
>   in Kconfig, which no longer does anything, so this should probably
>   be removed in patch 9 along with the lines that select it.

I think it better fits patch 1 that removes CONFIG_NUMA, patch 9 is about
SPARSEMEM.
 
> * It appears that after your series, RISC-V is the only remaining
>   architecture that supports NUMA in 32-bit mode, which I think
>   we should not allow as a configuration, given that this would
>   run into untested code and no hardware exists for it.
>   Apparently commit 4f0e8eef772e ("riscv: Add numa support for
>   riscv64 platform") intended this to only be for 64-bit targets
>   but did not add a Kconfig dependency for CONFIG_64BIT (or
>   CONFIG_SMP, which was added later).

I can send a patch to RISC-V for it.
 
>         Arnd

-- 
Sincerely yours,
Mike.

Hi Mike,

On Mon, 2026-04-13 at 13:46 +0300, Mike Rapoport wrote:
> NUMA support for SuperH was introduced a long time ago by commit
> b241cb0c885e ("sh: Support for multiple nodes.")
> 
> 	"... for boards with many different memory blocks that are
> 	 otherwise unused (SH7722/SH7785 URAM and so forth)"
> 
> In reality, this added 128K of memory on sh7722 and sh7785 and 256K on
> shx3 at the expense of all the NUMA related code in the kernel.
> 
> For build of v7.0-rc7 with defconfig and the same configuration with
> CONFIG_NUMA disabled, bloat-o-meter reports difference of ~76k. Disabling
> CONFIG_SPARSMEM on top increases the difference to ~94k. And that's only
> overhead in code and static data that does not take into the account data
> structures allocated at run time.
> 
> And all this overhead has been there for nothing for almost 8 years
> because since commit ac21fc2dcb40 ("sh: switch to NO_BOOTMEM")
> those additional "nodes" could not be used by the core MM because the
> maximal pfn for ZONE_NORMAL was cut out at the end of the normal memory.
> 
> Mike Rapoport (Microsoft) (10):
>   sh: remove CONFIG_NUMA and realted configuration options
>   sh: mm: remove numa.c
>   sh: mm: drop allocate_pgdat()
>   sh: remove setup_bootmem_node() and plat_mem_setup()
>   sh: drop dead code guarded by #ifdef CONFIG_NUMA
>   sh: drop include/asm/mmzone.h
>   init/Kconfig: drop ARCH_WANT_NUMA_VARIABLE_LOCALITY
>   sh: init: remove call the memblock_set_node()
>   sh: remove SPARSEMEM related entries from Kconfig
>   sh: drop include/asm/sparsemem.h

Thanks a lot for the series. It will take me some time to review and I expect
it to be taken for v7.2. FWIW, I actually own several boards using the SH-7785LCR
CPU and I issues booting kernels newer than 6.5 on these so I'm wondering whether
this broken feature might be to blame?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Hi Adrian,

On Mon, Apr 13, 2026 at 12:57:49PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Mike,
> 
> On Mon, 2026-04-13 at 13:46 +0300, Mike Rapoport wrote:
> > NUMA support for SuperH was introduced a long time ago by commit
> > b241cb0c885e ("sh: Support for multiple nodes.")
> > 
> > 	"... for boards with many different memory blocks that are
> > 	 otherwise unused (SH7722/SH7785 URAM and so forth)"
> > 
> > In reality, this added 128K of memory on sh7722 and sh7785 and 256K on
> > shx3 at the expense of all the NUMA related code in the kernel.
> > 
> > For build of v7.0-rc7 with defconfig and the same configuration with
> > CONFIG_NUMA disabled, bloat-o-meter reports difference of ~76k. Disabling
> > CONFIG_SPARSMEM on top increases the difference to ~94k. And that's only
> > overhead in code and static data that does not take into the account data
> > structures allocated at run time.
> > 
> > And all this overhead has been there for nothing for almost 8 years
> > because since commit ac21fc2dcb40 ("sh: switch to NO_BOOTMEM")
> > those additional "nodes" could not be used by the core MM because the
> > maximal pfn for ZONE_NORMAL was cut out at the end of the normal memory.
> > 
> > Mike Rapoport (Microsoft) (10):
> >   sh: remove CONFIG_NUMA and realted configuration options
> >   sh: mm: remove numa.c
> >   sh: mm: drop allocate_pgdat()
> >   sh: remove setup_bootmem_node() and plat_mem_setup()
> >   sh: drop dead code guarded by #ifdef CONFIG_NUMA
> >   sh: drop include/asm/mmzone.h
> >   init/Kconfig: drop ARCH_WANT_NUMA_VARIABLE_LOCALITY
> >   sh: init: remove call the memblock_set_node()
> >   sh: remove SPARSEMEM related entries from Kconfig
> >   sh: drop include/asm/sparsemem.h
> 
> Thanks a lot for the series. It will take me some time to review and I expect
> it to be taken for v7.2.

Yes, this for v7.2.

> FWIW, I actually own several boards using the SH-7785LCR CPU and I issues
> booting kernels newer than 6.5 on these so I'm wondering whether this
> broken feature might be to blame?

If 6.5 boots successfully, I don't think this is related.
 
> Adrian

-- 
Sincerely yours,
Mike.