From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/1] KVM: make get dirty log ioctl return the first dirty page's position Date: Wed, 24 Feb 2010 11:42:48 +0200 Message-ID: <4B84F498.50405@redhat.com> References: <20100224174303.881da4f4.yoshikawa.takuya@oss.ntt.co.jp> <4B84E985.8000508@redhat.com> <4B84EA63.8030405@redhat.com> <4B84EF4F.8050906@oss.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mtosatti@redhat.com, kvm@vger.kernel.org To: Takuya Yoshikawa Return-path: Received: from mx1.redhat.com ([209.132.183.28]:36674 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755706Ab0BXJmy (ORCPT ); Wed, 24 Feb 2010 04:42:54 -0500 In-Reply-To: <4B84EF4F.8050906@oss.ntt.co.jp> Sender: kvm-owner@vger.kernel.org List-ID: On 02/24/2010 11:20 AM, Takuya Yoshikawa wrote: > > Another issue I am thinking is the x86's bitmap allocation. Doing > vmalloc() > every time is not nice, though I know it's needed. > Right, that's why I want to move the allocation to userspace. >> >> btw, one idea I had was to allocate the bitmap in userspace and let >> the kernel set bits directly. This reduces the amount of unswappable >> memory the kernel allocates and reduces copying. >> >> A problem with this is that userspace cannot just clear the bits, >> since the kernel has to write-protect the pages again. I don't know >> how we can do this without copying the bitmap. >> > > Yes, seems difficult. Here's an idea: double buffering. Instead of copying the dirty log to userspace, we switch the dirty log bitmap to another location atomically. Then userspace can read the old bitmap. Note the speed savings won't be huge, since the copying brings the bitmap into cache, so the second pass is fairly fast. But if we combine it with dropping the qemu byte-based dirty log, then we eliminate the second pass as well. -- error compiling committee.c: too many arguments to function