On Tue, Jun 26, 2012 at 02:31:26PM -0700, Frank Swiderski wrote: > On Tue, Jun 26, 2012 at 1:40 PM, Rik van Riel <riel@xxxxxxxxxx> wrote: > > On 06/26/2012 04:32 PM, Frank Swiderski wrote: > >> > >> 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<fes@xxxxxxxxxx> > > > > > > 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. > > > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
