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 10:02:32 -0600 Message-ID: <53D91718.7010100@mail.usask.ca> References: <53D81C40.9020800@mail.usask.ca> <53D88C16.5090006@linux.vnet.ibm.com> <53D8A18D.2050607@mail.usask.ca> <53D91266.80906@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: Paolo Bonzini , 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]:38458 "EHLO smtp-out-05.shaw.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754109AbaG3QCe (ORCPT ); Wed, 30 Jul 2014 12:02:34 -0400 In-Reply-To: <53D91266.80906@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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