From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1OB5Xv-0005x3-Tz for qemu-devel@nongnu.org; Sun, 09 May 2010 08:23:47 -0400 Received: from [140.186.70.92] (port=56258 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OB5Xs-0005ul-CR for qemu-devel@nongnu.org; Sun, 09 May 2010 08:23:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OB5XU-0006gH-63 for qemu-devel@nongnu.org; Sun, 09 May 2010 08:23:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14780) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OB5XT-0006g8-Ux for qemu-devel@nongnu.org; Sun, 09 May 2010 08:23:20 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o49CNHxS020477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 9 May 2010 08:23:18 -0400 Date: Sun, 9 May 2010 15:29:17 +0300 From: Izik Eidus Message-ID: <20100509152917.43d112af@redhat.com> In-Reply-To: <20100413123318.0f2cd334@redhat.com> References: <20100413123318.0f2cd334@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] fix migration with large mem List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Izik Eidus Cc: qemu-devel@nongnu.org On Tue, 13 Apr 2010 12:33:18 +0300 Izik Eidus wrote: > From f881b371e08760a67bf1f5b992a586c3de600f7a Mon Sep 17 00:00:00 2001 > From: Izik Eidus > Date: Tue, 13 Apr 2010 12:24:57 +0300 > Subject: [PATCH] fix migration with large mem Anyone ??? > > In cases of guests with large mem that have pages > that all their bytes content are the same, we will > spend alot of time reading the memory from the guest > (is_dup_page()) > > It is happening beacuse ram_save_live() function have > limit of how much we can send to the dest but not how > much we read from it, and in cases we have many is_dup_page() > hits, we might read huge amount of data without updating important > stuff like the timers... > > The guest lose all its repsonsibility and have many softlock ups > inside itself. > > this patch add limit on the size we can read from the guest each > iteration. > > Thanks. > > Signed-off-by: Izik Eidus > --- > arch_init.c | 6 +++++- > 1 files changed, 5 insertions(+), 1 deletions(-) > > diff --git a/arch_init.c b/arch_init.c > index cfc03ea..e27b1a0 100644 > --- a/arch_init.c > +++ b/arch_init.c > @@ -88,6 +88,8 @@ const uint32_t arch_type = QEMU_ARCH; > #define RAM_SAVE_FLAG_PAGE 0x08 > #define RAM_SAVE_FLAG_EOS 0x10 > > +#define MAX_SAVE_BLOCK_READ 10 * 1024 * 1024 > + > static int is_dup_page(uint8_t *page, uint8_t ch) > { > uint32_t val = ch << 24 | ch << 16 | ch << 8 | ch; > @@ -175,6 +177,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, void *opaque) > uint64_t bytes_transferred_last; > double bwidth = 0; > uint64_t expected_time = 0; > + int data_read = 0; > > if (stage < 0) { > cpu_physical_memory_set_dirty_tracking(0); > @@ -205,10 +208,11 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, void *opaque) > bytes_transferred_last = bytes_transferred; > bwidth = qemu_get_clock_ns(rt_clock); > > - while (!qemu_file_rate_limit(f)) { > + while (!qemu_file_rate_limit(f) && data_read < MAX_SAVE_BLOCK_READ) { > int ret; > > ret = ram_save_block(f); > + data_read += ret * TARGET_PAGE_SIZE; > bytes_transferred += ret * TARGET_PAGE_SIZE; > if (ret == 0) { /* no more blocks */ > break;