Hi Paolo, Dave,
On 2017/4/26 23:46, Paolo Bonzini wrote:
>
>
> On 24/04/2017 18:42, Dr. David Alan Gilbert wrote:
>> I suppose there's a few questions;
>> a) Do we actually need the BQL - and if so why
Enable/disable dirty log tracking are operations on memory regions.
That's why they need to be in BQL I think.
>> b) What actually takes 13s? It's probably worth figuring
>> out where it goes, the whole bitmap is only 1GB isn't it
>> even on a 4TB machine, and even the simplest way to fill
>> that takes way less than 13s.
I found two time consuming operations in KVM module,
- one is kvm_mmu_slot_apply_flags(), when enable dirty log tracking
kvm_vm_ioctl_set_memory_region
|->kvm_set_memory_region
|->__kvm_set_memory_region
|->kvm_arch_commit_memory_region
|->kvm_mmu_slot_apply_flags
...
- the other is kvm_mmu_zap_collapsible_sptes(), when disable dirty log tracking
kvm_vm_ioctl_set_memory_region
|->kvm_set_memory_region
|->__kvm_set_memory_region
|->kvm_arch_commit_memory_region
|->kvm_mmu_zap_collapsible_sptes
...
Any ideas that could optimize the time spending for these operations?
>
> It's more likely that it is the migration_bitmap_sync immediately after
> that.
It's not, it's enable/disable dirty log tracking that costs time.
>
> I think it is possible to move migration_bitmap_sync outside BQL. It
> should be simpler to evaluate that after Juan's cleanups go in.
>
> Paolo
>
--
Thanks,
Yang
