Re: dirty page tracking in kvm/qemu -- page faults inevitable?

[Paolo Bonzini <pbonzini@redhat.com>]

Il 30/07/2014 09:41, Chris Friesen ha scritto:
>> I am afraid that using dirty-bit instead of write-protection may cause the case
>> even more worse for iothread-lock because we need to walk whole sptes to get
>> dirty-set pages, however currently we only need to walk the page set in the
>> bitmap.
> 
> I found a document at
> "http://ftp.software-sources.co.il/Processor_Architecture_Update-Bob_Valentine.pdf"
> which talks about the benefits of Haswell.  One of the items reads:
> 
> "New Accessed and Dirty bits for Extended Page Tables (EPT) eliminates
> major cause of vmexits"
> 
> Is that accurate?  If so, then it seems like it should allow for the VM
> to run without trying to exit the hypervisor, and as long as it just
> does in-memory operations it won't contend on the iothread lock.

True, but:

1) the problem is fishing the information out of the page tables and
passing it up to userspace.  You have to process the whole EPT tree one
page at a time, instead of doing it 64 bits at a time.  Also, one source
of bad performance is having to split all entries of the EPT page tables
down to 4K, and you get that anyway.

2) You should not get to userspace simply for marking a page as locked.
 As you describe it, your problem seems to be contention between QEMU
threads, KVM is not involved.

3) What version of QEMU are you using?  Things have been improving
steadily, and we probably will get to using atomic operations instead of
the iothread lock to protect the migration dirty bitmap.

Paolo