Re: [PATCH 00/10] sh: remove NUMA and SPARSEMEM support

[Mike Rapoport <rppt@kernel.org>]

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.