From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrmC9-0006Y5-Jr for qemu-devel@nongnu.org; Thu, 29 Oct 2015 08:20:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZrmC6-00084t-82 for qemu-devel@nongnu.org; Thu, 29 Oct 2015 08:20:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48231) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrmC5-00084h-UU for qemu-devel@nongnu.org; Thu, 29 Oct 2015 08:20:38 -0400 From: Juan Quintela In-Reply-To: <007101d11174$ef2b83e0$cd828ba0$@samsung.com> (Pavel Fedin's message of "Wed, 28 Oct 2015 14:36:48 +0300") References: <012c01d110a6$cd61cf90$68256eb0$@samsung.com> <87k2q8e8d4.fsf@neno.neno> <002b01d110c0$4a5c8e40$df15aac0$@samsung.com> <877fm7b9h2.fsf@neno.neno> <007101d11174$ef2b83e0$cd828ba0$@samsung.com> Date: Thu, 29 Oct 2015 13:20:34 +0100 Message-ID: <871tcdq31p.fsf@neno.neno> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] migration: Introduce migration_in_completion() Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Fedin Cc: 'Amit Shah' , Michael Tsirkin , qemu-devel@nongnu.org, 'Luiz Capitulino' Pavel Fedin wrote: > 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 ? ok, your problem here is that you modify ram. Could you take a look at how vhost manage this? It is done at migration_bitmap_sync(), and it just marks the pages that are dirty. The "just" part in the interesting bit. It uses the memory_region operations. Michael, do you understand that code better than me, could you give an introduction and say if it would work for the ITS? Thanks. Later, Juan.