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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Wed, Jun 22, 2011 at 5:47 PM, Shriram Rajagopalan <rshriram@xxxxxxxxx> wrote:
> On Wed, Jun 22, 2011 at 4:23 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
> wrote:
>>
>> On Sun, 2011-06-19 at 05:32 +0100, Shriram Rajagopalan wrote:
>> > This patch series adds checkpoint compression functionality to Remus.
>>
>> Would there be any benefit to applying this technique to the second and
>> subsequent rounds of a normal live migration? Or do you need the greater
>> number of rounds which Remus implies to really see the benefit?
>>
> The benefits (bandwidth wise) will show up from 3rd round or so. 1st round,
> since
> "all" pages are sent as-is, they are not cached. 2nd round is where you
> would
> start caching pages. 3rd round onwards, you would see the benefits of the
> compression
> (depending on the workload in the VM).

So it sounds like the amount of bandwidth savings depends on how many
rounds you go after the 2nd round; I'm not sure how many that is on
average, but it seems unlikely to be too large.

On the other hand, if there's not too much of a cost, it might
actually make the code simpler to send compressed checkpoints by
default, rather than by gating them on Remus.

 -George

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