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

[Chris Friesen <cbf123@mail.usask.ca>]

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