Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for
fast (de)inflating & fast live migration

On Thu, Dec 15, 2016 at 05:40:45PM -0800, Dave Hansen wrote:

quoted

On 12/15/2016 05:38 PM, Li, Liang Z wrote:

quoted

Use 52 bits for 'pfn', 12 bits for 'length', when the 12 bits is not long

enough for the 'length'

quoted

quoted

Set the 'length' to a special value to indicate the "actual length in next 8

bytes".

quoted

quoted

That will be much more simple. Right?

Sounds fine to me.

Sounds fine to me too indeed.

I'm only wondering what is the major point for compressing gpfn+len in
8 bytes in the common case, you already use sg_init_table to send down two
pages, we could send three as well and avoid all math and bit shifts and ors,
or not?

Yes, we can use more pages for that.

I agree with the above because from a performance prospective I tend to
think the above proposal will run at least theoretically faster because the
other way is to waste double amount of CPU cache, and bit mangling in the
encoding and the later decoding on qemu side should be faster than
accessing an array of double size, but then I'm not sure if it's measurable
optimization. So I'd be curious to know the exact motivation and if it is to
reduce the CPU cache usage or if there's some other fundamental reason to
compress it.
The header already tells qemu how big is the array payload, couldn't we just
add more pages if one isn't enough?

The original intention to compress the PFN and length it's to reduce the memory required.
Even the code was changed a lot from the previous versions, I think this is still true.

Now we allocate a specified buffer size to save the 'PFN|length', when the buffer is not big
enough to save all the page info for a specified order. A double size buffer will be allocated.
This is what we want to avoid because the allocation may fail and allocation takes some time,
for fast live migration, time is a critical factor we have to consider, more time takes means
more unnecessary pages are sent, because live migration starts before the request for unused
 pages get response. 

Thanks

Liang

Thanks,
Andrea