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 -- 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
