[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


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.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.