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

[David Hildenbrand]

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?

--
Cheers,

David / dhildenb