Re: [PATCH 0 of 2] [Resend v2] remus: Checkpoint Compression

[George Dunlap <george.dunlap@citrix.com>]

If I understand the patch correctly,the compression is of a special
kind: it's not gzipped, but the new page is compared to the previous
page, and only the differences sent.  (This is done in a clever way to
be computationally efficient.)

So simply running the whole stream through gzip won't have the same
effect: it won't take advantage of the fact that most of the data
already exists on the remote side, and only send the differences.  So it
will most likely take more computation power to compress, and end up
with a higher bandwitdh.

 -George

On Tue, 2011-06-21 at 16:18 +0100, Ian Jackson wrote:
> Shriram Rajagopalan writes ("[Xen-devel] [PATCH 0 of 2] [Resend v2] remus: Checkpoint Compression"):
> > This patch series adds checkpoint compression functionality to Remus.
> 
> Can I ask a rather fundamental question: why is it a good idea to hook
> this page compression logic into the guts of the already-complicated
> migration code, rather than simply using transport compression for the
> whole remus stream ?
> 
> The latter would be a good deal simpler.
> 
> Ian.