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 :-)
