qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface
Date: Wed, 05 Oct 2011 07:46:34 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 10/05/2011 06:28 AM, Michael S. Tsirkin wrote:
On Mon, Oct 03, 2011 at 10:00:48AM -0500, Anthony Liguori wrote:
Yes, it's easy to quantify. I think the following gives us
the offset before and after, so the difference is the size
we seek, right?

OK, Orit (Cc'd) did some research - this is a booting
while still in grub, size probably does not get much less than that.
windows is said to be much more aggressive in allocating memory.

  start offset: 9600673
  end offset: 9614933

So we get 15K out of 9M.

So, let's do some napkin math.

Assume that it works out that most of that 15k are 4 byte integers. If we assume an average name length of 6 characters, a string should be encoded in 8 bytes. That means for every 4 bytes, we add 8 bytes which means we're increasing by 200%.

That means 45k.

A 1gbit link can xmit at max, 128k in 1ms. So that extra 30k is going to cost ~250us in transmit time if we can get 1gbit. A the default rate limit, it should cost us right around 1ms.

I guess it's liveable although with 30 network cards, I suspect it gets a heck of a lot worse.

Regards,

Anthony Liguori

By the way, most of the memory here is pretty much
all uniform I guess, because compressing it gets us:
gzip: 1934169
bzip2 -9: 1462551

So even with aggressive compression, we probably won't be able to get
below 1.5M for memory, two orders of magnitude above device state.

Sounds convincing?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]