|
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?
[Prev in Thread] | Current Thread | [Next in Thread] |