Re: [libvirt PATCH v3 5/5] qemu: enable asynchronous teardown on s390x hosts by default
On Wed, 5 Jul 2023 14:08:27 +0100
Daniel P. Berrangé <berrange(a)redhat.com> wrote:
On Wed, Jul 05, 2023 at 02:46:03PM +0200, Claudio Imbrenda wrote:
> On Wed, 5 Jul 2023 13:26:32 +0100
> Daniel P. Berrangé <berrange(a)redhat.com> wrote:
>
> [...]
>
> > > > I rather think mgmt apps need to explicitly opt-in to async
teardown,
> > > > so they're aware that they need to take account of delayed RAM
> > > > availablity in their accounting / guest placement logic.
> > >
> > > what would you think about enabling it by default only for guests that
> > > are capable to run in Secure Execution mode?
> >
> > IIUC, that's basically /all/ guests if running on new enough hardware
> > with prot_virt=1 enabled on the host OS, so will still present challenges
> > to mgmt apps needing to be aware of this behaviour AFAICS.
>
> I think there is some fencing still? I don't think it's automatic
IIUC, the following sequence is possible
1. Start QEMU with -m 500G
-> QEMU spawns async teardown helper process
2. Stop QEMU
-> Async teardown helper process remains running while
not running, the process terminates immediately as soon as QEMU
terminates. the termination takes some time, because of the memory
cleanup.
kernel releases RAM
3. Start QEMU with -m 500G
-> Fails with ENOMEM
why though? the new VM will not manage to instantly use all of the
memory
...time passes...
4. Async teardown helper finally terminates
-> The full original 500G is only now released for use
memory starts to get freed as soon as the helper process terminates
(which is as immediately as possible after QEMU terminates
so unless you have a guest that will allocate and use all of its memory
immediately as fast as possible at boot, this won't be a concern.
Basically if you can't do
while true
do
virsh start $guest
virsh stop $guest
done
then it is a change in libvirt API semantics, as so will require
explicit opt-in from the mgmt app to use this feature.
this is still true, though, because you __could__ have a guest that
zeroes out (or otherwise touches) all memory immediately when booting,
I guess?
see Thomas' comment, though
With regards,
Daniel