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@xxxxxxxxx> 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@xxxxxxxxx> 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
