Virtualization - Nov 2021 - [PATCH v2] virtio_balloon: add param to skip adjusting pages

On 18.11.21 10:11, David Stevens wrote:
> From: David Stevens <stevensd at chromium.org>
Hi David,
> 
> Add a module parameters to virtio_balloon to allow specifying whether or
> not the driver should call adjust_managed_page_count. If the parameter
> is set, it overrides the default behavior inferred from the deflate on
> OOM flag. This allows the balloon to operate without changing the amount
> of memory visible to userspace via /proc/meminfo or sysinfo, even on a
> system that cannot set the default on OOM flag.
> 
> The motivation for this patch is to allow userspace to more accurately
> take advantage of virtio_balloon's cooperative memory control on a
> system without the ability to use deflate on OOM. As it stands,
> userspace has no way to know how much memory may be available on such a
> system, which makes tasks such as sizing caches impossible.
But that user space also has no idea "when" that memory will become
available, it could be never. This problem is similar to memory hotplug,
where we don't know "when" more memory might get hotplugged.

With deflate-on-OOM this behavior makes sense, because the guest can use
that memory whenever it wants -- it's actually available as soon as we
need it.
> 
> When deflate on OOM is not enabled, the current behavior of the
> virtio_balloon more or less resembles hotplugging individual pages, at
> least from an accounting perspective. This is basically hardcoding the
> requirement that totalram_pages must be available to the guest
> immediately, regardless of what the host does. While that is a valid
> policy, on Linux (which supports memory overcommit) with virtio_balloon
> (which is designed to facilitate overcommit in the host), it is not the
> only possible policy.
> 
> The param added by this patch allows the guest to operate under the
> assumption that pages in the virtio_balloon will generally be made
> available when needed. This assumption may not always hold, but when it
> is violated, the guest will just fall back to the normal mechanisms for
> dealing with overcommitted memory.
> 
> Independent of what policy the guest wants, the virtio_balloon device
> does not consider pages in the balloon as contributing to the guest's
> total amount of memory if deflate on OOM is not enabled. Ensure that the
> reported stats are consistent with this by adjusting totalram if a
> guest without deflate on OOM is skipping the calls to
> adjust_managed_page_count.
What about simply exposing the number of inflated balloon pages
("logically offline pages") e.g., via /proc/meminfo to user space?
It's
then up to smart user space trying to be smart about memory that's not
available right now and might never become available eventually in the
future -- but still that user space wants to optimize for some eventuality.

-- 
Thanks,

David / dhildenb