From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Friesen Subject: Re: dirty page tracking in kvm/qemu -- page faults inevitable? Date: Wed, 30 Jul 2014 01:41:01 -0600 Message-ID: <53D8A18D.2050607@mail.usask.ca> References: <53D81C40.9020800@mail.usask.ca> <53D88C16.5090006@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: Xiao Guangrong , avi@redhat.com, mtosatti@redhat.com, kvm@vger.kernel.org Return-path: Received: from smtp-out-05.shaw.ca ([64.59.134.13]:42532 "EHLO smtp-out-05.shaw.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754969AbaG3HlH (ORCPT ); Wed, 30 Jul 2014 03:41:07 -0400 In-Reply-To: <53D88C16.5090006@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/30/2014 12:09 AM, Xiao Guangrong wrote: > On 07/30/2014 06:12 AM, Chris Friesen wrote: >> Hi, >> >> I've got an issue where we're hitting major performance penalties while doing live migration, and it seems like it might >> be due to page faults triggering hypervisor exits, and then we get stuck waiting for the iothread lock which is held by >> the qemu dirty page scanning code. > > 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. Chris