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?