From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MInSh-0001vc-RG for qemu-devel@nongnu.org; Mon, 22 Jun 2009 13:37:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MInSd-0001sD-5P for qemu-devel@nongnu.org; Mon, 22 Jun 2009 13:37:43 -0400 Received: from [199.232.76.173] (port=49655 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MInSc-0001s2-Rq for qemu-devel@nongnu.org; Mon, 22 Jun 2009 13:37:38 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]:56799) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MInSc-0007IF-EA for qemu-devel@nongnu.org; Mon, 22 Jun 2009 13:37:38 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n5MHZVo0023068 for ; Mon, 22 Jun 2009 11:35:32 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5MHbaqr251396 for ; Mon, 22 Jun 2009 11:37:36 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n5MHbZ3V019459 for ; Mon, 22 Jun 2009 11:37:35 -0600 Message-ID: <4A3FC15D.1020705@us.ibm.com> Date: Mon, 22 Jun 2009 12:37:33 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [Qemu-commits] [COMMIT 3086844] Instead of writing a zero page, madvise it away References: <200906221549.n5MFn3Qd015389@d03av02.boulder.ibm.com> <4A3FAD69.60507@redhat.com> <4A3FB077.4040607@codemonkey.ws> <4A3FB390.4060809@redhat.com> <4A3FB95D.3060404@us.ibm.com> <4A3FBD61.8030109@redhat.com> In-Reply-To: <4A3FBD61.8030109@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel Avi Kivity wrote: > You mean, a NONZERO bit which is cleared by ballooning and set on any > write. This will work naturally with the qemu dirty bytemap. Yes. >> >> For KVM, we would have to enable dirty tracking always to keep >> ZERO_DIRTY up to date. Since write faults are going to happen anyway >> at start up, perhaps the cost of doing this wouldn't be so bad? > > You need to do this on the source node. Unfortunately, there's no way > to initialize the values racelessly when you start live migration > without introducing a new ioctl. I'd like a more general solution > rather than something that targets this specific problem. I'm saying, always enable dirty tracking from start-of-day with KVM. Then the QEMU dirty bitmap is always accurate. The trick is to never start resetting it until you need to do live migration. The idea being that once the dirty bits have been set, the overhead (hopefully) should be zero. -- Regards, Anthony Liguori