public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Chris Friesen <cbf123@mail.usask.ca>,
	Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
	mtosatti@redhat.com, kvm@vger.kernel.org
Subject: Re: dirty page tracking in kvm/qemu -- page faults inevitable?
Date: Wed, 30 Jul 2014 18:18:50 +0200	[thread overview]
Message-ID: <53D91AEA.8040009@redhat.com> (raw)
In-Reply-To: <53D91718.7010100@mail.usask.ca>

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

      reply	other threads:[~2014-07-30 16:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-29 22:12 dirty page tracking in kvm/qemu -- page faults inevitable? Chris Friesen
2014-07-30  6:09 ` Xiao Guangrong
2014-07-30  7:41   ` Chris Friesen
2014-07-30 15:42     ` Paolo Bonzini
2014-07-30 16:02       ` Chris Friesen
2014-07-30 16:18         ` Paolo Bonzini [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53D91AEA.8040009@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=cbf123@mail.usask.ca \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=xiaoguangrong@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox