On 5/15/20 4:41 PM, Sean Christopherson wrote: > On Fri, May 15, 2020 at 02:28:54PM -0700, Anthony Yznaga wrote: >> Hi, >> >> I'm investigating optimizing qemu start time for large memory guests, >> and I'm trying to understand why kvm_mmu_slot_apply_flags() is called by >> kvm_arch_commit_memory_region() for KVM_MR_CREATE. The comments in >> kvm_mmu_slot_apply_flags() imply it should be, but what I've observed is >> that the new slot will have no mappings resulting in slot_handle_level_range() >> walking the rmaps and doing nothing. This can take a noticeable amount of >> time for very large ranges. It doesn't look like there would ever be any >> mappings in a newly created slot. Am I missing something? > > I don't think so. I've stared at that call more than once trying to figure > out why it's there. AFAICT, the original code was completely unoptimized, > then the DELETE check got added as the obvious "this is pointless" case. > Note, KVM_MR_MOVE is in the same boat as CREATE; it's basically DELETE+CREATE. > > There can theoretically be rmaps for the new/moved memslot, but they should > already be up-to-date since they're consuming the new memslot's properties. > > I've always been too scared to remove it and didn't have a strong argument > for doing so :-) > Thanks, Sean. This is my first foray into kvm code so I'm still getting familiar with the code. I haven't studied the KVM_MR_MOVE case yet, but it sounds like kvm_mmu_slot_apply_flags() may only do useful work for the KVM_MR_FLAGS_ONLY case. Anthony
