"Michael S. Tsirkin" <> writes:
> Also copy virtio-dev since this in clearly implementation ...
>
> On Thu, Jan 30, 2014 at 07:34:30PM +1030, Rusty Russell wrote:
>> Hi,
>>
>>
I tried to write a new balloon driver; it's completely untested
>> (as I need to write the device). The protocol is basically two vqs, one
>> for the guest to send commands, one for the host to send commands.
>>
>> Some interesting things come out:
>> 1) We do need to explicitly tell the host where the page is we want.
>>
This is required for compaction, for example.
>>
>> 2) We need to be able to exceed the balloon target, especially for page
>>
migration. Thus there's no mechanism for the device to refuse to
>>
give us the pages.
>>
>> 3) The device can offer multiple page sizes, but the driver can only
>>
accept one. I'm not sure if this is useful, as guests are either
>>
huge page backed or not, and returning sub-pages isn't useful.
>>
>> Linux demo code follows.
>>
>> Cheers,
>> Rusty.
>
> More comments:
> - for projects like auto-ballooning that Luiz works on,
> it's not nice that to swap page 1 for page 2
> you have to inflate then deflate
> besides overhead this confuses the host:
> imagine you tell QEMU to increase target,
> meanwhile guest inflates temporarily,
> QEMU thinks okay done, now you suddenly deflate.
I originally allowed the host to deny the deflate, which was why I
reversed it. Then I realized that was a bad idea. I can switch it back.
> - what's the status of page returned from balloon?
> is it zeroed or can it have old data in there?
> I think in practice Linux will sometimes map in a zero page,
> so guest can save cycles and avoid zeroing it out.
> I think we should tell this to guest when returning
> pages.
QEMU may not know, since the kernel may not tell it. We should assume
nothing, and let the guest zero if it needs to. Seems like a premuture
optimization.
> - I am guessing EXTRA_MEM is for uses like the ones proposed by
> Frank Swiderski from google that inflate/deflate balloon
>
whenever guest wants (look for "Add a page cache-backed balloon
> device driver").
>
>
this is useful but - we need to distinguish pages
> like this from regular inflate.
> it's not just counter and host needs a way to know
> that it's target is reached
The driver needs to explicitly ask for pages in that region.
> - do we even want to allow guest not telling host when it wants
> to reuse the page?
> if yes, I think this should be per-page somehow: when balloon
> is inflated guest should tell host whether it
> expects to use this page.
I decided against it. Making that optional got us into a mess, so now
it's compulsory. That also fits better with the idea of a negative
balloon.
> So I think we should accomodate these uses, and so we want the following flags:
>
> - WEAK_TARGET (that's the EXTRA_MEM but I think done in a better way)
>
flag that specifies pages do not count against target,
> can be taken out of balloon.
> EXTRA_MEM suggests there's an upper limit on balloon size
> but IMHO that's just extra work for host: host does not care
> I think, give it as much as you want.
> set by guest, used by host
I think that Daniel really does want more memory than the guest starts
with. And I think he still wants to use the balloon to control it.
Daniel?
> - TELL_HOST flag that specifies guest will tell host before using pages
> (that's VIRTIO_BALLOON_F_MUST_TELL_HOST
> at the moment, listed here for completeness)
> set by guest, used by host
Dislike.
> - ZEROED
> flag that specifies that page returned to guest
> is zeroed
> set by host, used by guest
I think that's silly. Under Linux the guest doesn't need to know it's
zeroed or not, it just frees the page.
> Each of the flags can be just a feature flag, and then
> if we wants a mix of them host can create multiple
> balloon devices with differnet flags, and guest looks for best
> balloon for its purposes.
>
> Alternatively flags can be set and reported per page.
>
>
> A couple of other suggestions:
>
> - how to accomodate memory pressure in guest?
>
Let's add a field telling host how hard do we
>
want our memory back
That's very hard to define across guests. Should we be using stats for
that instead? In fact, should we allow gratuitous stats sending,
instead of a simple NEED_MEM flag?
> - assume you want to over-commit host and start
>
inflating balloon.
>
If low on memory it might be better for guest to
>
wait a bit before inflating.
>
Also, if host asks for a lot of memory a ton of
>
allocations will slow guest significantly.
>
But for guest to do the right thing we need host to tell guest what
>
are its memory and time contraints.
>
Let's add a field telling guest how hard do we
>
want it to give us memory (e.g. time limit)
We can't have intelligence at both ends, I think. We've chosen a
host-led model, so we should stick to that unless someone has an
implementation which proves its worth doing otherwise.
Cheers,
Rusty.
