> 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: > > On 12/15/2016 05:38 PM, Li, Liang Z wrote: > > > > > > Use 52 bits for 'pfn', 12 bits for 'length', when the 12 bits is not long > enough for the 'length' > > > Set the 'length' to a special value to indicate the "actual length in next 8 > bytes". > > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
