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

[Mike Rapoport <rppt@kernel.org>]

Hi Adrian,

On Thu, Jul 02, 2026 at 11:54:59AM +0200, John Paul Adrian Glaubitz wrote:
> Hi,
> 
> On Thu, 2026-07-02 at 12:37 +0300, Mike Rapoport (Microsoft) wrote:
> > 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.
> > 
> > ---
> > It's been another few weeks without updates from Adrian and I don't see
> > why it should wait more.
> > 
> > @Andrew, please take it to the mm tree.
> 
> I feel like this is an attempt to force me to give up as a maintainer.

This isn't an attempt to force you to give up, this is an attempt to merge
patches that have been out there for long time.

They are related to mm because we are talking about mm features. And it is
long standing practice that Andrew takes patches that fall between the
cracks.

v1 went out in the middle of April, there were no comments at all from you
almost for a month and I sent v2 on May 10th.

We are in July now, so this is definitely falling between the cracks.
 
> Otherwise, I can't really understand why you are building up so much
> pressure for a niche and hobbyist architecture

By pressure you mean an email in a few weeks?!

This isn't about sh, this is about reducing NUMA and SPARSEMEM_STATIC
footprint to ease the maintenance.

A niche and hobbyist architecture does not need NUMA and SPARSEMEM.
And for sh particularly they should have not be enabled at the first place.
 
> Adrian

-- 
Sincerely yours,
Mike.