Re: [PATCH being tested] KVM: Reduce mmu_lock contention during dirty logging by cond_resched()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Thu, 12 Apr 2012 19:56:45 -0300
Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote:

> Other than potential performance improvement, the worst case scenario
> of holding mmu_lock for hundreds of milliseconds at the beginning 
> of migration of huge guests must be fixed.

Write protection in kvm_arch_commit_memory_region() can be treated

I am now checking that part together with my
	KVM: Avoid zapping unrelated shadows in __kvm_set_memory_region()
because if we do rmap-based write protection when we enable dirty-logging,
sp->slot_bitmap necessary for kvm_mmu_slot_remove_write_access() can be

People who want to support more devices/slots will be happy, no?

But then, I need to find another way to eliminate shadow flushes.
Maybe I should leave sp->slot_bitmap removal to those who really want to
do that.

> > @@ -3121,15 +3121,23 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log)
> >  		if (!dirty_bitmap[i])
> >  			continue;
> >  
> > -		is_dirty = true;
> > -
> >  		mask = xchg(&dirty_bitmap[i], 0);
> >  		dirty_bitmap_buffer[i] = mask;
> >  
> >  		offset = i * BITS_PER_LONG;
> > -		kvm_mmu_write_protect_pt_masked(kvm, memslot, offset, mask);
> > +		nr_protected += kvm_mmu_write_protect_pt_masked(kvm, memslot,
> > +								offset, mask);
> > +		if (nr_protected > 2048) {
> Can you expand on the reasoning behind this?


To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[KVM ARM]     [KVM ia64]     [KVM ppc]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Linux Kernel]     [Linux SCSI]     [XFree86]

Add to Google Powered by Linux