[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2b8f4855-98f4-4515-bd5f-f93983d45714@redhat.com>
Date: Mon, 18 Dec 2023 16:18:01 +0100
From: David Hildenbrand <david@...hat.com>
To: David Stevens <stevensd@...omium.org>
Cc: "Michael S . Tsirkin" <mst@...hat.com>,
virtualization@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] virtio_balloon: stay awake while adjusting balloon
On 18.12.23 16:16, David Stevens wrote:
> On Mon, Dec 18, 2023 at 6:37 AM David Hildenbrand <david@...hat.com> wrote:
>>
>> On 14.12.23 05:13, David Stevens wrote:
>>> On Wed, Dec 13, 2023 at 5:44 PM David Hildenbrand <david@...hat.com> wrote:
>>>>
>>>> On 11.12.23 12:43, David Stevens wrote:
>>>>> From: David Stevens <stevensd@...omium.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
Powered by blists - more mailing lists