> On Sep 29, 2026, at 16:44, Muchun Song <[email protected]> wrote:
>
>
>
>> On Sep 29, 2026, at 15:39, David Hildenbrand (Arm) <[email protected]> wrote:
>>
>> On 9/27/26 04:54, Muchun Song wrote:
>>> 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.
>
>>
>> Change itself looks good.
>>
>> Acked-by: David Hildenbrand (Arm) <[email protected]>
>
> Thanks for your review.
>
> Muchun,
> Thanks
>
>>
>> --
>> Cheers,
>>
>> David
