From mboxrd@z Thu Jan  1 00:00:00 1970
From: George Dunlap <george.dunlap@eu.citrix.com>
Subject: Re: [PATCH 6 of 8 [RFC]] libxc: introduce
	xc_domain_move_memory
Date: Thu, 2 May 2013 16:07:14 +0100
Message-ID: <51828122.7000900@eu.citrix.com>
References: <patchbomb.1365475745@hit-nxdomain.opendns.com>
	<e4fdc6439df798df4738.1365475751@hit-nxdomain.opendns.com>
	<20130502143209.GL65547@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20130502143209.GL65547@ocelot.phlegethon.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Tim Deegan <tim@xen.org>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, Ian Campbell <Ian.Campbell@citrix.com>, Andrew Cooper <Andrew.Cooper3@citrix.com>, Juergen Gross <juergen.gross@ts.fujitsu.com>, Olaf Hering <olaf@aepfle.de>, xen-devel <xen-devel@lists.xen.org>, David Vrabel <dvrabel@cantab.net>, Keir Fraser <keir.xen@gmail.com>, Andres Lagar-Cavilla <andres@lagarcavilla.org>, Jan Beulich <JBeulich@suse.com>, Dario Faggioli <dario.faggioli@citrix.com>, Roger Pau Monne <roger.pau@citrix.com>
List-Id: xen-devel@lists.xenproject.org

On 02/05/13 15:32, Tim Deegan wrote:
> Hi,
>
> This looks like a promising start.  Two thoughts:
>
> 1. You currently move memory into a bufferm free it, allocate new memory
>     and restore the contents.  Copying directly from old to new would be
>     significantly faster, and you could do it for _most_ batches:
>     - copy old batch 0 to the backup buffer; free old batch 0;
>     - allocate new batch 1; copy batch 1 directly; free old batch 1;
>       ...
>     - allocate new batch n; copy batch n directly; free old batch n;
>     - allocate new batch 0; copy batch 0 from the backup buffer.

Hmm -- isn't it the case that if there is not *free* memory lying around 
somewhere, then this operation is fairly pointless?  What will happen is 
that after freeing batch 0, "allocate new batch 1" will get that 
memory.  So copying it to a temporary buffer in dom0 seems like not a 
particularly useful thing to do -- it should try to allocate a new 
buffer to copy into directly, and if that fails, just say "No point 
trying -- no empty memory to move into."

Unless of course we were trying to do this to two (or more) VMs at the 
same time, but that seems like the next level.

  -George