question: KVM_MR_CREATE and kvm_mmu_slot_apply_flags()

question: KVM_MR_CREATE and kvm_mmu_slot_apply_flags()

[Anthony Yznaga]

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?

Thanks,
Anthony

Re: question: KVM_MR_CREATE and kvm_mmu_slot_apply_flags()

[Sean Christopherson]

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

Re: question: KVM_MR_CREATE and kvm_mmu_slot_apply_flags()

[Anthony]

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