Re: [PATCH v5 08/12] mm/sparse-vmemmap: move vmemmap optimization helpers to a public header

On Sep 29, 2026, at 16:44, Muchun Song [off-list ref] wrote:

quoted

On Sep 29, 2026, at 15:39, David Hildenbrand (Arm) [off-list ref] wrote:

On 9/27/26 04:54, Muchun Song wrote:

quoted

The vmemmap optimization helpers currently live in mm/sparse.h,
which is an internal MM header. That works for MM code, but
prevents powerpc from using the same interfaces without including a
private header.

Move the declarations and inline helpers to vmemmap-optimization.h.
This is a preparatory change for powerpc, which has its own vmemmap
optimization implementation and needs to use the common vmemmap
optimization interfaces from architecture code.

Which raises the question why powerpc was special and will remain special. Wha's
the big problem here that powerpc must do special things?

Good question. I also don't think PowerPC needs special handling,
but when HVO logic was introduced for PowerPC, it handled HVO on
its own. From my preliminary analysis, the reason it didn't reuse
the generic logic initially may be related to the fact that
PowerPC's section size is 16M. With a 64k base page, a single page
can cover the vmemmap range of multiple sections, and the current
generic logic doesn't cover this case.

I looked at the code in my local branch for removing the PowerPC
vmemmap optimization handling, and I found another issue that needs
to be addressed.

Since PowerPC vmemmap optimization is restricted to Radix, this only
needs to cover the Radix page-table implementation.

The generic vmemmap path currently allocates intermediate page-table
pages with vmemmap_alloc_block_zero(). This bypasses the normal
page-table constructors.

PowerPC Radix uses early_alloc_pgtable() before slab is available. For
runtime population, it uses pud_alloc(), pmd_alloc(), and
pte_alloc_kernel(). These helpers initialize the page-table metadata
and fragment reference counts expected by pud_free(), pmd_free(), and
pte_free_kernel() during hot-remove.

To address this, I plan to update the generic path so that it uses
the normal page-table helpers once slab is available, while retaining
memblock-backed allocations during early boot. Once allocation and
teardown are correctly paired, PowerPC Radix should be able to call
vmemmap_populate_hugepages() directly and remove its duplicate HVO
page-table walk.

Thanks,
Muchun

However, completely removing PowerPC's special handling is already
in my follow-up plan. We need to wait for the current series to enter
the mainline, and then we can proceed gradually.

quoted

Change itself looks good.

Acked-by: David Hildenbrand (Arm) <david@kernel.org>

Thanks for your review.

Muchun,
Thanks

quoted

-- 
Cheers,

David