From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44609) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBQPA-0005Fp-TR for qemu-devel@nongnu.org; Fri, 01 Mar 2013 08:53:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UBQP8-0004hl-Ub for qemu-devel@nongnu.org; Fri, 01 Mar 2013 08:53:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57894) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBQP8-0004hO-MO for qemu-devel@nongnu.org; Fri, 01 Mar 2013 08:53:42 -0500 Message-ID: <5130B2E0.6070401@redhat.com> Date: Fri, 01 Mar 2013 14:53:36 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <5130ADC0.9070402@dlhnet.de> <5130B29C.3060301@redhat.com> In-Reply-To: <5130B29C.3060301@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] migration: use XBZRLE only after bulk stage List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Orit Wasserman , Peter Lieven , "qemu-devel@nongnu.org" Il 01/03/2013 14:52, Eric Blake ha scritto: > On 03/01/2013 06:31 AM, Peter Lieven wrote: >> at the beginning of migration all pages are marked dirty and >> in the first round a bulk migration of all pages is performed. >> >> currently all these pages are copied to the page cache regardless >> if there are frequently updated or not. this doesn't make sense >> since most of these pages are never transferred again. >> >> this patch changes the XBZRLE transfer to only be used after >> the bulk stage has been completed. that means a page is added >> to the page cache the second time it is transferred and XBZRLE >> can benefit from the third time of transfer. >> >> since the page cache is likely smaller than the number of pages >> its also likely that in the second round the page is missing in the >> cache due to collisions in the bulk phase. >> >> on the other hand a lot of unneccssary mallocs, memdups and frees > > s/unneccssary/unnecessary/ > >> are saved. >> >> Signed-off-by: Peter Lieven > > Do you have any benchmark numbers? At any rate, the explanation seems > sound, so a benchmark should show this. It probably would be much less of a problem with the pending patches to move RAM migration out of the big QEMU lock. However, the explanation makes sense. Paolo >> --- >> arch_init.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) > > Reviewed-by: Eric Blake >