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

On 5/12/26 09:46, Michal Hocko wrote:
> 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 protected] 
>>
>> Signed-off-by: David Hildenbrand (Arm) <[email protected]>
>> ---
>> 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 protected]>

Thanks!

> to all patches but kmemleak one which I do not feel qualified to judge.

It's black magic to me as well. I tried to test that scenario in particular and
was not able to trigger the problem.

-- 
Cheers,

David