Re: [PATCH v6 03/11] KVM: arm64: Relax locking for kvm_test_age_gfn and kvm_age_gfn

[Oliver Upton <oliver.upton@linux.dev>]

Hey David,

On Fri, Aug 30, 2024 at 08:33:59AM -0700, David Matlack wrote:
> On Thu, Aug 29, 2024 at 5:48 PM Oliver Upton <oliver.upton@linux.dev> wrote:
> >
> > On Thu, Aug 29, 2024 at 05:33:00PM -0700, James Houghton wrote:
> > > On Mon, Aug 19, 2024 at 1:42 PM Oliver Upton <oliver.upton@linux.dev> wrote:
> > > > Asking since you had a setup / data earlier on when you were carrying
> > > > the series. Hopefully with supportive data we can get arm64 to opt-in
> > > > to HAVE_KVM_MMU_NOTIFIER_YOUNG_FAST_ONLY as well.
> > >
> > > I'll keep trying some other approaches I can take for getting similar
> > > testing that Yu had; it is somewhat difficult for me to reproduce
> > > those tests (and it really shouldn't be.... sorry).
> >
> > No need to apologize. Getting good test hardware for arm64 is a complete
> > chore. Sure would love a functional workstation with cores from this
> > decade...
> >
> > > I think it makes most sense for me to drop the arm64 patch for now and
> > > re-propose it (or something stronger) alongside enabling aging. Does
> > > that sound ok?
> >
> > I'm a bit disappointed that we haven't gotten forward progress on the
> > arm64 patches, but I also recognize this is the direction of travel as
> > the x86 patches are shaping up.
> >
> > So yeah, I'm OK with it, but I'd love to get the arm64 side sorted out
> > soon while the context is still fresh.
> 
> Converting the aging notifiers to holding mmu_lock for read seems like
> a pure win and minimal churn. Can we keep that patch in v7 (which
> depends on the lockless notifier refactor, i.e. is not completely
> stand-alone)? We can revisit enabling MGLRU on arm64 in a subsequent
> series.

Even though the churn is minimal in LOC, locking changes are significant. If
one thing has become clear, there are some strong opinions about arm64
participating in MGLRU w/ the read lock. So it is almost guaranteed that
these read lock changes will eventually get thrown out in favor of an
RCU-protected walker.

Then we're stuck with potentially 3 flavors of locking in kernels that
people actually use, and dealing with breakage that only affects that
intermediate step is gonna be annoying.

-- 
Thanks,
Oliver