I had no intention of globally disabling it. I just need to disable it
for my use case.
Well, yes and no.
For the current balloon driver, it doesn't make much sense. It would
add a fair amount of complexity without any real gain. It's currently
based around alloc_page/free_page. When it wants to shrink the domain
and give memory back to the host, it allocates pages, adds the page
structures to a ballooned pages list, and strips off the backing memory
and gives it to the host. Growing the domain is the converse: it gets
pages from the host, pulls page structures off the list, binds them
together and frees them back to the kernel. If it runs out of ballooned
page structures, it hotplugs in some memory to add more.
That said, if (partial-)sections were much smaller - say 2-4 meg - and
page migration/defrag worked reliably, then we could probably do without
the balloon driver and do it all in terms of memory hot plug/unplug.
That would give us a general mechanism which could either be driven from
userspace, and/or have in-kernel Xen/kvm/s390/etc policy modules. Aside
from small sections, the only additional requirement would be an online
hook which can actually attach backing memory to the pages being
onlined, rather than just assuming an underlying DIMM as current code does.
In Xen, either the host or the guest can set the target size for the
domain, which is capped by the host-set limit. Aside from possibly
setting the target size, there's no usermode involvement in managing
ballooning. The virtio balloon driver is similar, though from a quick
look it seems to be entirely driven by the host side.
J
--
