From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH 0 of 2] [Resend v2] remus: Checkpoint Compression Date: Tue, 21 Jun 2011 16:25:11 +0100 Message-ID: <1308669911.30420.294.camel@elijah> References: <19968.46678.954904.31629@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <19968.46678.954904.31629@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: Shriram Rajagopalan , George Dunlap , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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.