On 07/30/2014 09:42 AM, Paolo Bonzini wrote:
Il 30/07/2014 09:41, Chris Friesen ha scritto:
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.
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.
What about writing to a page where we're tracking dirty pages? Would
that get back up to qemu or would that be handled entirely in the kvm
kernel module?
I was assuming that it was due to the page faults since as far as I know
the app in the VM is just doing packet processing from/to memory-mapped
circular buffers--the qemu threads in question aren't doing "normal" I/O
but something is causing them to try to acquire the iothread lock.
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.
We're currently on 1.4.2. We're looking at trying out 1.7 to see if
it's better, but we've got some local patches that would need to get ported.
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
