On 07/30/2014 12:09 AM, Xiao Guangrong wrote:
On 07/30/2014 06:12 AM, Chris Friesen wrote:
Hi,
I've got an issue where we're hitting major performance penalties while doing live migration, and it seems like it might
be due to page faults triggering hypervisor exits, and then we get stuck waiting for the iothread lock which is held by
the qemu dirty page scanning code.
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.
Chris
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
