Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 18 Dec 2023 16:18:01 +0100 | Subject | Re: [PATCH] virtio_balloon: stay awake while adjusting balloon | From | David Hildenbrand <> |
| |
On 18.12.23 16:16, David Stevens wrote: > On Mon, Dec 18, 2023 at 6:37 AM David Hildenbrand <david@redhat.com> wrote: >> >> On 14.12.23 05:13, David Stevens wrote: >>> On Wed, Dec 13, 2023 at 5:44 PM David Hildenbrand <david@redhat.com> wrote: >>>> >>>> On 11.12.23 12:43, David Stevens wrote: >>>>> From: David Stevens <stevensd@chromium.org> >>>>> >>>> >>>> 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
| ![\](/images/icornerr.gif) |