qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] migration: Introduce migration_in_completion()


From: Pavel Fedin
Subject: Re: [Qemu-devel] [PATCH] migration: Introduce migration_in_completion()
Date: Wed, 28 Oct 2015 14:36:48 +0300

 Hello!

> Power people have a similar problem with its hashed page tables, they
> integrated their own save_live implementation because they are too big
> for the last stage.  You can look there for inspiration.

 I examined their code. Interesting, and, indeed, it opens up a way for 
decreasing downtime by implementing iterative migration for
the ITS.
 However, this is not really what is necessary. This thing aims to produce own 
data chunk, and it's not good for ITS. ITS already
stores everything in system RAM, therefore savevm_ram_handlers take perfect 
care about these data. The only thing to do is to tell
the ITS to dump its state into RAM. This is what i currently do using 
migration_in_completion().
 An alternate, perhaps better approach, would be to be able to hook into 
ram_save_iterate() and ram_save_complete(). This way we
could kick ITS right before attempting to migrate RAM.
 Could we extend the infrastructure so that:
a) Handlers are prioritized, and we can determine order of their execution?
b) We can choose whether our handlers actually produce extra chunk or not?

 OTOH, what i've done is actually a way to hook up into save_live_complete 
before any other registered handlers get executed. What
is missing is one more notifier_list_notify() call right before 
qemu_savevm_state_iterate(), and a corresponding
migration_is_active() checker.

 What do you think ?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia





reply via email to

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