[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (d
From: |
Li, Liang Z |
Subject: |
Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration |
Date: |
Sat, 17 Dec 2016 12:39:01 +0000 |
> 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
- Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration, (continued)
- Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration, Michael S. Tsirkin, 2016/12/15
- Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration, Li, Liang Z, 2016/12/15
- Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration, Andrea Arcangeli, 2016/12/16
- Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration, Li, Liang Z, 2016/12/17
- Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration, Li, Liang Z, 2016/12/15
- Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration, Dave Hansen, 2016/12/15
- Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration, Li, Liang Z, 2016/12/15
- Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration, Dave Hansen, 2016/12/15
- Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration, Li, Liang Z, 2016/12/15
- Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration, Andrea Arcangeli, 2016/12/16
- Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration,
Li, Liang Z <=