qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH V2 00/11] Live update: cpr-exec


From: David Hildenbrand
Subject: Re: [PATCH V2 00/11] Live update: cpr-exec
Date: Mon, 5 Aug 2024 11:52:35 +0200
User-agent: Mozilla Thunderbird

On 04.08.24 17:43, Peter Xu wrote:
On Mon, Jul 22, 2024 at 10:59:47AM +0200, David Hildenbrand wrote:
So I wonder whether there's comparison between exec() and transfer mode
that you recently proposed.

I'm asking because exec() (besides all the rest of things that I dislike on
it in this approach..) should be simply slower, logically, due to the
serialized operation to (1) tearing down the old mm, (2) reload the new
ELF, then (3) runs through the QEMU init process.

If with a generic migration solution, the dest QEMU can start running (2+3)
concurrently without even need to run (1).

I'll note (not sure if already discussed) that with the "async-teardown"
option we have a way to move the MM teardown to a separate process, such
that it will happen asynchronously.

I just had a look, maybe it won't trivially work, as it relies on QEMU
process to quit first..

async_teardown_fn():
     if (the_ppid == getppid()) {
         pause();
     }

While if we stick with exec(), then PID shouldn't change, so the teardown
process can hold the mm and pause until the VM is destroyed..

Right, the mechanism would have to be extended to realize that exec() happened. Notifying the child before exec() would be undesired, so it would have to happen after exec() from the changed parent.

Sounds doable, but certainly doesn't come for free!

--
Cheers,

David / dhildenb




reply via email to

[Prev in Thread] Current Thread [Next in Thread]