A primary advantage of virtio balloon over other memory reclaim mechanisms is that it can pressure the guest's page cache into shrinking.
However, since the balloon driver changed to using the shrinker API <https://github.com/torvalds/linux/commit/71994620bb25a8b109388fefa9e99a28e355255a#diff-fd202acf694d9eba19c8c64da3e480c9> this use case has become a bit more tricky. I'm wondering what the intended device implementation is. When inflating the balloon against page cache (i.e. no free memory remains) vmscan.c will both shrink page cache, but also invoke the shrinkers -- including the balloon's shrinker. So the balloon driver allocates memory which requires reclaim, vmscan gets this memory by shrinking the balloon, and then the driver adds the memory back to the balloon. Basically a busy no-op. If file IO is ongoing during this balloon inflation then the page cache could be growing which further puts "back pressure" on the balloon trying to inflate. In testing I've seen periods of > 45 seconds where balloon inflation makes no net forward progress. This wasn't a problem before the change to the shrinker API since forced balloon deflation only occurred via the OOM notifier callback which was invoked only after the page cache had depleted. Is this new busy behavior working as intended?
_______________________________________________ Virtualization mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/virtualization
