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

Mike Rapoport <[email protected]>
Newsgroups gmane.linux.ports.sh.devel,gmane.linux.kernel,gmane.linux.kernel.mm
Message-ID <[email protected]>
(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 <[email protected]>

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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.