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

[Vincent Donnefort]

On Tue, Nov 03, 2026 at 08:22:47AM +0000, Marc Zyngier wrote:
> 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.

Yes, "fast fail" would be a far better description.

> 
> - 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.

I have booted with qemu a L1 guest. Pinned to the biggest CPUs of the Mac M2 and
set the performance governor.

Then in the L1 guest, I disabled completely THPs and enabled the tracing
function_graph to measure user_mem_abort() and get_user_mapping_size(), before
booting a L2 guest with a single vCPU.

That gave me something like ...

 0)               |  user_mem_abort() {
 0)   0.208 us    |    get_user_mapping_size();
 0)   5.958 us    |  }

I have skipped the outliers (the function_graph prefix them with '+', '$' ...)
which I believe are most likely related to interrupts.

Then for each pair, I got the percentage get_user_mapping_size() represents in
the user_mem_abort() execution time.

Now looking again at the results I have, I realised I gave the mean (5%) but
perhaps the median which is 2.7% is a better representation of the overall
improvement and is slightly less impressive.

-- 
Vincent

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