Linux Virtualization - Dec 2016 - [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> On 12/15/2016 04:48 PM, Li, Liang Z wrote:
> >>> It seems we leave too many bit  for the pfn, and the bits
leave for
> >>> length is not enough, How about keep 45 bits for the pfn and
19 bits
> >>> for length, 45 bits for pfn can cover 57 bits physical
address, that
> >>> should be
> >> enough in the near feature.
> >>> What's your opinion?
> >> I still think 'order' makes a lot of sense.  But, as you
say, 57 bits
> >> is enough for
> >> x86 for a while.  Other architectures.... who knows?
> 
> Thinking about this some more...  There are really only two cases that
> matter: 4k pages and "much bigger" ones.
> 
> Squeezing each 4k page into 8 bytes of metadata helps guarantee that this
> scheme won't regress over the old scheme in any cases.  For bigger
ranges, 8
> vs 16 bytes means *nothing*.  And 16 bytes will be as good or better than
> the old scheme for everything which is >4k.
> 
> How about this:
>  * 52 bits of 'pfn', 5 bits of 'order', 7 bits of
'length'
>  * One special 'length' value to mean "actual length in next 8
bytes"
> 
> That should be pretty simple to produce and decode.  We have two record
> sizes, but I think it is manageable.
It works,  Now that we intend to use another 8 bytes for length

Why not:

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?

Liang

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.

> 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.
Thanks for your inspiration!

Liang

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?

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?

Thanks,
Andrea