From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takuya Yoshikawa Subject: Re: [PATCH 0/1] KVM: make get dirty log ioctl return the first dirty page's position Date: Wed, 24 Feb 2010 18:20:15 +0900 Message-ID: <4B84EF4F.8050906@oss.ntt.co.jp> References: <20100224174303.881da4f4.yoshikawa.takuya@oss.ntt.co.jp> <4B84E985.8000508@redhat.com> <4B84EA63.8030405@redhat.com> 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: Avi Kivity Return-path: Received: from serv2.oss.ntt.co.jp ([222.151.198.100]:56207 "EHLO serv2.oss.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755926Ab0BXJRy (ORCPT ); Wed, 24 Feb 2010 04:17:54 -0500 In-Reply-To: <4B84EA63.8030405@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: >> >> 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. Actually I do not know well about migration's use case in the actual service system. In our group, there is a Fault Tolerance project which uses migration's functions for synchronization frequently. So I thought this may be helpful to such cases, not confirmed yet. Another issue I am thinking is the x86's bitmap allocation. Doing vmalloc() every time is not nice, though I know it's needed. > > 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.