From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37274 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNp2T-000172-ST for qemu-devel@nongnu.org; Wed, 01 Dec 2010 10:57:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNp1j-0007iz-2I for qemu-devel@nongnu.org; Wed, 01 Dec 2010 10:56:12 -0500 Received: from mail-qy0-f173.google.com ([209.85.216.173]:45282) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNp1i-0007iL-VJ for qemu-devel@nongnu.org; Wed, 01 Dec 2010 10:55:27 -0500 Received: by qyk1 with SMTP id 1so2813925qyk.4 for ; Wed, 01 Dec 2010 07:55:25 -0800 (PST) Message-ID: <4CF66FEB.7030602@codemonkey.ws> Date: Wed, 01 Dec 2010 09:55:23 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <411b3f89b6b79b429686bd1b1fa188ba55b6c6f7.1290552026.git.quintela@redhat.com> <4CF45DE0.8020701@codemonkey.ws> <4CF65FBB.3020406@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 10/10] Maintaing number of dirty pages List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Avi Kivity , qemu-devel@nongnu.org On 12/01/2010 09:51 AM, Juan Quintela wrote: > Avi Kivity wrote: > >> On 11/30/2010 04:46 PM, Juan Quintela wrote: >> >>> Anthony Liguori wrote: >>> >>>> On 11/23/2010 05:03 PM, Juan Quintela wrote: >>>> >>>>> From: Juan Quintela >>>>> >>>>> Calculate the number of dirty pages takes a lot on hosts with lots >>>>> of memory. Just maintain how many pages are dirty. Only sync bitmaps >>>>> if number is small enough. >>>>> >>>>> >>>> There needs to be numbers that justify this as part of the commit message. >>>> >>> They are on patch 0/6. >>> >>> Additionally, with 64GB of RAM, this bitmap is HUGE, having to walk over >>> it in each ram_save_live() call is too onerous. >>> >> It's not so huge. It's scaled down by a factor of 8 * 4096 = 32K. So >> it's a 2MB bitmap. If kept as a bitmap and accessed in longs, it can >> be read in less than a millisecond. BTW, by this logic, even a 1-byte dirty bitmap is only 16mb which can be read in less than 16ms so where is the reported 24 minute stall coming from? Regards, Anthony Liguori