WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 1 of 2] tools/libxc: Remus Checkpoint Compression

To: Shriram Rajagopalan <rshriram@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 1 of 2] tools/libxc: Remus Checkpoint Compression
From: Brendan Cully <brendan.cully@xxxxxxxxxx>
Date: Thu, 16 Jun 2011 09:34:29 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, ian.jackson@xxxxxxxxxxxxx
Delivery-date: Thu, 16 Jun 2011 18:53:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <5dbafaf24c7036f3e24e.1308239406@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Mail-followup-to: Shriram Rajagopalan <rshriram@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, ian.jackson@xxxxxxxxxxxxx
References: <patchbomb.1308239405@xxxxxxxxxxxxxxxxxxx> <5dbafaf24c7036f3e24e.1308239406@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21+22 (8d0281f79b21) (2010-12-30)
On Thursday, 16 June 2011 at 08:50, Shriram Rajagopalan wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@xxxxxxxxx>
> # Date 1308238095 25200
> # Node ID 5dbafaf24c7036f3e24e4387797b32e59d732ac6
> # Parent  23c068b109236657ededa3e3b7f180346a5cd9f9
> tools/libxc: Remus Checkpoint Compression
> 
> Instead of sending dirty pages of guest memory as-is, use a simple compression
> algorithm that sends a RLE-encoded XOR of the page against its last sent copy.
> A small LRU cache is used to hold recently dirtied pages. Pagetable pages are
> sent as-is, as they are canonicalized at sender side and uncanonicalized at
> receiver.
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@xxxxxxxxx>
...
> @@ -1395,6 +1455,7 @@
>          }
>  
>          pagebuf.nr_physpages = pagebuf.nr_pages = 0;
> +        pagebuf.compbuf_pos = pagebuf.compbuf_size = 0;
>  
>          n += j; /* crude stats */
>  

Is that zeroing compbuf_size at the end of every round? Does that mean
you're doing a realloc for every single page you ever receive? Ouch.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel