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

[Vincent Donnefort <vdonnefort@google.com>]

On Wed, Nov 11, 2026 at 09:23:34AM +0000, Marc Zyngier wrote:
> On Tue, 03 Nov 2026 14:26:33 +0000,
> Vincent Donnefort <vdonnefort@google.com> wrote:
> > 
> > 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@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.
> 
> Oh crap, this is *nested*! No wonder things take ages, as you end-up
> going via S2 (and any miss in a TLB is pretty taxing). This really
> should be captured in the commit message...
> 
> What is the impact on a non-NV setup?

I do all the testing with nested: it works great, and it makes sure I don't
break the machine :) 

I have tried on an Ampere Altra machine and the results are actually
interesting: get_user_mapping() seems on average taking just as much time
(0.26us). However the whole user_mem_abort() is also shorter (2.3us) so the
percentage is actually higher: 13% on average.

-- 
Vincent

> 
> > 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.
> 
> Yeah, but still. Please respin this with an amended commit message,
> and we'll see how we route this.
> 
> Thanks,
> 
> 	M.
> 
> -- 
> Without deviation from the norm, progress is not possible.