Subject: Re: [PATCH 0/8] mm: remove CONFIG_HAVE_BOOTMEM_INFO_NODE (Part 1)

From: Michal Hocko <[email-masked]>
Date: Tue, 12 May 2026 09:46:09 +0200

On Mon 11-05-26 16:05:28, David Hildenbrand wrote:
> We want to remove CONFIG_HAVE_BOOTMEM_INFO_NODE. As a first step,
> let's limit the remaining harm to x86 and core code, removing
> sparc, ppc and s390 leftovers, starting the stepwise removal by removing
> and simplifying some code.
> 
> Once a related x86 vmemmap fix [1] is in, we can merge part 2 that will
> remove CONFIG_HAVE_BOOTMEM_INFO_NODE entirely.
> 
> Tested on x86-64 with hugetlb vmemmap optimization in combination with
> KMEMLEAK, making sure that the problem reported in dd0ff4d12dd2 ("bootmem:
> remove the vmemmap pages from kmemleak in put_page_bootmem") does not
> reappear -- hoping I managed to trigger the original problem.
> 
> Heavily cross-compiled, but let's let build bots run on it for a bit.
> 
> [1] https://lore.kernel.org/r/[email-masked] 
> 
> Signed-off-by: David Hildenbrand (Arm) <[email-masked]>
> ---
> David Hildenbrand (Arm) (8):
>       sparc/mm: remove register_page_bootmem_info()
>       mm/bootmem_info: drop initialization of page->lru
>       mm/bootmem_info: stop using PG_private
>       mm/bootmem_info: remove call to kmemleak_free_part_phys()
>       mm/bootmem_info: stop marking the pgdat as NODE_INFO
>       mm/bootmem_info: stop marking mem_section_usage as MIX_SECTION_INFO
>       s390/mm: use free_reserved_page() in vmem_free_pages()
>       powerpc/mm: remove CONFIG_HAVE_BOOTMEM_INFO_NODE
> 
>  arch/powerpc/mm/init_64.c    |  8 --------
>  arch/s390/mm/vmem.c          |  3 +--
>  arch/sparc/mm/init_64.c      | 20 --------------------
>  include/linux/bootmem_info.h |  1 -
>  mm/Kconfig                   |  2 +-
>  mm/bootmem_info.c            | 25 ++-----------------------
>  6 files changed, 4 insertions(+), 55 deletions(-)

Good clean up. Feel free to add
Acked-by: Michal Hocko <[email-masked]>
to all patches but kmemleak one which I do not feel qualified to judge.

Thanks!

-- 
Michal Hocko
SUSE Labs