Re: [PATCH] virtio_balloon: stay awake while adjusting balloon

[David Stevens]

On Mon, Dec 18, 2023 at 10:18 AM David Hildenbrand <david@xxxxxxxxxx> wrote:
>
> On 18.12.23 16:16, David Stevens wrote:
> > On Mon, Dec 18, 2023 at 6:37 AM David Hildenbrand <david@xxxxxxxxxx> wrote:
> >>
> >> On 14.12.23 05:13, David Stevens wrote:
> >>> On Wed, Dec 13, 2023 at 5:44 PM David Hildenbrand <david@xxxxxxxxxx> wrote:
> >>>>
> >>>> On 11.12.23 12:43, David Stevens wrote:
> >>>>> From: David Stevens <stevensd@xxxxxxxxxxxx>
> >>>>>
> >>>>
> >>>> Hi David,
> >>>>
> >>>>> Add a wakeup event for when the balloon is inflating or deflating.
> >>>>> Userspace can enable this wakeup event to prevent the system from
> >>>>> suspending while the balloon is being adjusted. This allows
> >>>>> /sys/power/wakeup_count to be used without breaking virtio_balloon's
> >>>>> cooperative memory management.
> >>>>
> >>>> Can you add/share some more details
> >>>
> >>> I'm working on enabling support for Linux s2Idle in our Android
> >>> virtual machine, to restrict apps from running in the background
> >>> without holding an Android partial wakelock. With the patch I recently
> >>> sent out [1], since crosvm advertises native PCI power management for
> >>> virtio devices, the Android guest can properly enter s2idle, and it
> >>> can be woken up by incoming IO. However, one of the remaining problems
> >>> is that when the host needs to reclaim memory from the guest via the
> >>> virtio-balloon, there is nothing preventing the guest from entering
> >>> s2idle before the balloon driver finishes returning memory to the
> >>> host.
> >>
> >> Thanks for the information. So you also want to wakeup the VM when
> >> wanting to get more memory from the VM?
> >>
> >> Using which mechanism would that wakeup happen? Likely not the device
> >> itself?
> >
> > The wakeup would happen via the parent device's interrupt. I've sent a
> > new version of this patch that uses the parent device's wakeup event
> > instead of adding a new one.
> >
> >>>
> >>> One alternative to this approach would be to add a virtballoon_suspend
> >>> callback to abort suspend if the balloon is inflating/adjusting.
> >>> However, it seems cleaner to just prevent suspend in the first place.
> >>
> >> Also, the PM notifier could also be used with very high priority, so the
> >> device would respond early to PM_SUSPEND_PREPARE.
> >
> > One drawback of blocking suspend via a PM notifier is that the
> > behavior isn't configurable by userspace, whereas wakeup events can be
> > enabled/disabled by userspace.
>
> The question is if that behavior for the balloon is really worth it
> being configured by user space?

It seems to me that the current behavior of completely resetting the
virtio balloon in virtballoon_freeze is basically antithetical to the
power management integration I'm adding, where power management
doesn't interrupt the virtio balloon's operation at all. So if there
are any systems that are actually happy with the current power
management behavior, they probably don't want suspend to be blocked by
inflation/deflation.

-David