Re: [PATCH] Add a page cache-backed balloon device driver.

On Tue, Jun 26, 2012 at 2:47 PM, Michael S. Tsirkin [off-list ref] wrote:

On Tue, Jun 26, 2012 at 02:31:26PM -0700, Frank Swiderski wrote:

quoted

On Tue, Jun 26, 2012 at 1:40 PM, Rik van Riel [off-list ref] wrote:

quoted

On 06/26/2012 04:32 PM, Frank Swiderski wrote:

quoted

This implementation of a virtio balloon driver uses the page cache to
"store" pages that have been released to the host.  The communication
(outside of target counts) is one way--the guest notifies the host when
it adds a page to the page cache, allowing the host to madvise(2) with
MADV_DONTNEED.  Reclaim in the guest is therefore automatic and implicit
(via the regular page reclaim).  This means that inflating the balloon
is similar to the existing balloon mechanism, but the deflate is
different--it re-uses existing Linux kernel functionality to
automatically reclaim.

Signed-off-by: Frank Swiderski<redacted>

It is a great idea, but how can this memory balancing
possibly work if someone uses memory cgroups inside a
guest?

Thanks and good point--this isn't something that I considered in the
implementation.

quoted

Having said that, we currently do not have proper
memory reclaim balancing between cgroups at all, so
requiring that of this balloon driver would be
unreasonable.

The code looks good to me, my only worry is the
code duplication. We now have 5 balloon drivers,
for 4 hypervisors, all implementing everything
from scratch...

Do you have any recommendations on this?  I could (I think reasonably
so) modify the existing virtio_balloon.c and have it change behavior
based on a feature bit or other configuration.  I'm not sure that
really addresses the root of what you're pointing out--it's still
adding a different implementation, but doing so as an extension of an
existing one.

fes

Let's assume it's a feature bit: how would you
formulate what the feature does *from host point of view*?

--
MST

In this implementation, the host doesn't keep track of pages in the
balloon, as there is no explicit deflate path.  The host device for
this implementation should merely, for example, MADV_DONTNEED on the
pages sent in an inflate.  Thus, the inflate becomes a notification
that the guest doesn't need those pages mapped in, but that they
should be available if the guest touches them.  In that sense, it's
not a rigid shrink of guest memory.  I'm not sure what I'd call the
feature bit though.

Was that the question you were asking, or did I misread?

fes