Il 30/07/2014 18:02, Chris Friesen ha scritto: > 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? It's handle inside the kernel module. Every now and then QEMU asks the kernel for the dirty pages and ORs the bitmap returned by KVM with its own. All this is done under the iothread lock. > 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. >From a quick "git describe" 2.0 is needed. The patches end at commit ae2810c (memory: syncronize kvm bitmap using bitmaps operations, 2013-11-05). Paolo -- 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
