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

[David Hildenbrand]

> > > I did something similar. Filled the balloon with 15GB for a 16GB idle
> > > guest, by
> > > using bitmap, the madvise count was reduced to 605. when using the
> > > PFNs, the madvise count
> > > was 3932160. It means there are quite a lot consecutive bits in the
> > > bitmap.
> > > I didn't test for a guest with heavy memory workload.
> >
> > Would it then even make sense to go one step further and report {pfn,
> > length} combinations?
> >
> > So simply send over an array of {pfn, length}?
>
> Li's current patches do that.  Well, maybe not pfn/length, but they do
> take a pfn and page-order, which fits perfectly with the kernel's
> concept of high-order pages.

So we can send length in powers of two. Still, I don't see any benefit
over a simple pfn/len schema. But I'll have a more detailed look at the
implementation first, maybe that will enlighten me :)

> > And it makes sense if you think about:
> >
> > a) hugetlb backing: The host may only be able to free huge pages (we
> > might want to communicate that to the guest later, that's another
> > story). Still we would have to send bitmaps full of 4k frames (512 bits
> > for 2mb frames). Of course, we could add a way to communicate that we
> > are using a different bitmap-granularity.
>
> Yeah, please read the patches.  If they're not clear, then the
> descriptions need work, but this is done already.

I missed the page_shift, thanks for the hint.

--

David