On Mon, Aug 19, 2024, Oliver Upton wrote: > On Fri, Aug 16, 2024 at 07:03:27PM -0600, Yu Zhao wrote: > > On Fri, Aug 16, 2024 at 6:46 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > [...] > > > > Were you expecting vCPU runtime to improve (more)? If so, lack of movement could > > > be due to KVM arm64 taking mmap_lock for read when handling faults: > > > > > > https://lore.kernel.org/all/Zr0ZbPQHVNzmvwa6@xxxxxxxxxx > > > > For the above test, I don't think it's mmap_lock > > Yeah, I don't think this is related to the mmap_lock. > > James is likely using hardware that has FEAT_HAFDBS, so vCPUs won't > fault for an Access flag update. Huh, didn't know that was a thing on ARM. Ooh, that lends even more credence to my assertion that marking folios accessed in handle_access_fault() can go away[*]. I assume hardware-assisted updates means this code in handle_access_fault() will no longer be hit, as KVM simply won't ever get access faults? If so, I'll add that info to the changelog. if (kvm_pte_valid(pte)) kvm_set_pfn_accessed(kvm_pte_to_pfn(pte)); [*] https://lore.kernel.org/all/20240726235234.228822-83-seanjc@xxxxxxxxxx > Even if he's on a machine w/o it, Access flag faults are handled outside the > mmap_lock. Oh, right, they go down handle_access_fault(), not user_mem_abort(). Reviewing late Friday afternoon, never a good idea ;-)
