Hi Yu Zhao,
On Thu, Nov 07, 2024 at 01:20:27PM -0700, Yu Zhao wrote:
> HVO was disabled by commit 060a2c92d1b6 ("arm64: mm: hugetlb: Disable
> HUGETLB_PAGE_OPTIMIZE_VMEMMAP") due to the following reason:
>
> This is deemed UNPREDICTABLE by the Arm architecture without a
> break-before-make sequence (make the PTE invalid, TLBI, write the
> new valid PTE). However, such sequence is not possible since the
> vmemmap may be concurrently accessed by the kernel.
>
> This series presents one of the previously discussed approaches to
> re-enable HugeTLB Vmemmap Optimization (HVO) on arm64.
Before jumping into the new mechanisms here, I'd really like to
understand how the current code is intended to work in the relatively
simple case where the vmemmap is page-mapped to start with (i.e. when we
don't need to worry about block-splitting).
In that case, who are the concurrent users of the vmemmap that we need
to worry about? Is it solely speculative references via
page_ref_add_unless() or are there others?
Looking at page_ref_add_unless(), what serialises that against
__hugetlb_vmemmap_restore_folio()? I see there's a synchronize_rcu()
call in the latter, but what prevents an RCU reader coming in
immediately after that?
Even if we resolve the BBM issues, we still need to get the
synchronisation right so that we don't e.g. attempt a cmpxchg() to a
read-only mapping, as the CAS instruction requires write permission on
arm64 even if the comparison ultimately fails.
So please help me to understand the basics of HVO before we get bogged
down by the block-splitting on arm64.
Cheers,
Will
