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

[Shriram Rajagopalan <rshriram@xxxxxxxxx>]

On Thu, Jun 23, 2011 at 6:55 AM, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:

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.

Yes. That is what I was driving at.

On the other hand, if there's not too much of a cost,

For compression, there is an additional overhead of 64M memory +
2 full page scans (original page + cached page) to compute the diff.
For Remus, small changes to a page get amplified to full page transmissions without compression.

And since Remus runs forever, this is bad in long term. OTOH, for live migration, while it makes
code simpler and possibly reduces bandwidth, is it worth the cost mentioned above?

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