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 10:59:15 +0200 Message-ID: <4B84EA63.8030405@redhat.com> References: <20100224174303.881da4f4.yoshikawa.takuya@oss.ntt.co.jp> <4B84E985.8000508@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; 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]:36947 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755251Ab0BXI7U (ORCPT ); Wed, 24 Feb 2010 03:59:20 -0500 In-Reply-To: <4B84E985.8000508@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/24/2010 10:55 AM, Avi Kivity wrote: > On 02/24/2010 10:43 AM, Takuya Yoshikawa wrote: >> Some weeks ago, OHMURA Kei revised the qemu-kvm's >> dirty bitmap scan by accessing the bitmap as an >> unsigned long array. >> >> By reviewing this work more, we notice that kernel >> side is doing a similar thing to check the bitmap is >> all clean or not. >> >> So I made a patch which makes the get dirty log ioctl >> return the first dirty page position found by this check. >> >> Though my test is not enough to show the effect of this >> patch, the fact that this patch has no bad effect to both >> performance and implementation logic and we can skip some >> extra memory accesses and comparisons in userspace seems >> to be suggesting this patch is promising, right? > > Well, if 10% of the pages are dirty, the new ioctl will statistically > return something within the first 20% of the slot, so we can skip 10% > and have to do the next 90%. Given that we already walked the bitmap > once in the kernel and the saving is only in userspace, the average > saving in bitmap-walking is only 5%. > > The patch's greatest benefit is if all pages are clean (100% saved) or > if just one page is dirty (50% saved) but that will be very rare. So > I think the return-on-churn here is too low. 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. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.