[PATCH v1] KVM: arm64: Fast path transparent_hugepage_adjust() for non-PMD folios

[Marc Zyngier]

On Mon, 02 Nov 2026 21:19:00 +0000,
Vincent Donnefort <vdonnefort at google.com> wrote:
> 
> transparent_hugepage_adjust() must walk the userspace stage-1 to detect
> if a PMD-level mapping is installed. If it is, then a stage-2 block
> mapping can be installed. Even though this stage-1 walk is most likely
> cache hot (in most cases, the mapping has just been installed), walking
> a page-table is still costly. This walks accounts for ~5% of the
> user_mem_abort() execution time on an Apple M2 big core. This makes a
> fast path interesting.

This raises a few questions:

- Isn't this a "fast fail" rather than a fast path? You don't make the
  S1 walk faster, but you instead avoid cases where it would have
  returned an level-3 size.

  If anything, you make transparent_hugepage_adjust() slower for the
  case that succeeds. I don't think this invalidates the approach, but
  it feels that the commit message is just wrong.

- How do you measure this? 5% feels like a huge amount for something
  that should be 3 loads. Isn't this more an indication that the page
  table walker is overly complicated because it was designed for
  something else? In any case, It'd be good to verify your findings,
  so please provide a minimal reproducer.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.