From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFwgd-0008UM-Tn for qemu-devel@nongnu.org; Tue, 18 Feb 2014 21:15:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFwgU-0002WH-2H for qemu-devel@nongnu.org; Tue, 18 Feb 2014 21:14:59 -0500 Received: from e9.ny.us.ibm.com ([32.97.182.139]:51125) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFwgT-0002W8-U4 for qemu-devel@nongnu.org; Tue, 18 Feb 2014 21:14:49 -0500 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 18 Feb 2014 21:14:49 -0500 Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 41825C9003E for ; Tue, 18 Feb 2014 21:14:44 -0500 (EST) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by b01cxnp22035.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s1J2El11721358 for ; Wed, 19 Feb 2014 02:14:47 GMT Received: from d01av05.pok.ibm.com (localhost [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s1J2Ekt1018616 for ; Tue, 18 Feb 2014 21:14:47 -0500 Message-ID: <5304138D.6070206@linux.vnet.ibm.com> Date: Wed, 19 Feb 2014 10:14:37 +0800 From: "Michael R. Hines" MIME-Version: 1.0 References: <1392713429-18201-1-git-send-email-mrhines@linux.vnet.ibm.com> <1392713429-18201-7-git-send-email-mrhines@linux.vnet.ibm.com> <53040215.2080102@cn.fujitsu.com> In-Reply-To: <53040215.2080102@cn.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v2 06/12] mc: introduce state machine changes for MC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Li Guang Cc: GILR@il.ibm.com, SADEKJ@il.ibm.com, quintela@redhat.com, BIRAN@il.ibm.com, hinesmr@cn.ibm.com, qemu-devel@nongnu.org, EREZH@il.ibm.com, owasserm@redhat.com, onom@us.ibm.com, junqing.wang@cs2c.com.cn, "Michael R. Hines" , gokul@us.ibm.com, dbulkow@gmail.com, pbonzini@redhat.com, abali@us.ibm.com, isaku.yamahata@gmail.com On 02/19/2014 09:00 AM, Li Guang wrote: > Hi, > > mrhines@linux.vnet.ibm.com wrote: >> From: "Michael R. Hines" >> >> This patch sets up the initial changes to the migration state >> machine and prototypes to be used by the checkpointing code >> to interact with the state machine so that we can later handle >> failure and recovery scenarios. >> >> Signed-off-by: Michael R. Hines >> --- >> arch_init.c | 29 ++++++++++++++++++++++++----- >> include/migration/migration.h | 2 ++ >> migration.c | 37 >> +++++++++++++++++++++---------------- >> 3 files changed, 47 insertions(+), 21 deletions(-) >> >> diff --git a/arch_init.c b/arch_init.c >> index db75120..e9d4d9e 100644 >> --- a/arch_init.c >> +++ b/arch_init.c >> @@ -658,13 +658,13 @@ static void ram_migration_cancel(void *opaque) >> migration_end(); >> } >> >> -static void reset_ram_globals(void) >> +static void reset_ram_globals(bool reset_bulk_stage) >> { >> last_seen_block = NULL; >> last_sent_block = NULL; >> last_offset = 0; >> last_version = ram_list.version; >> - ram_bulk_stage = true; >> + ram_bulk_stage = reset_bulk_stage; >> } >> > > here is a chance that ram_save_block will never break while loop > if loat_seen_block be reset for mc when there are no dirty pages > to be migrated. > > Thanks! I see. Question: While running the code, I have never seen a case where there are no dirty pages. Have you seen this before? And even if there are no dirty pages during a single 100 millisecond checkpoint interval (the default which can be changed) - the probability that there will continue to be no dirty pages during the next checkpoint interval will be very low, right? If there are no dirty pages during a checkpoint, should not ram_save_block() keep waiting? The virtual machine is still running during MC - the MC code does not stop the virtual machine, so if there are no dirty pages, isn't it safe to just let ram_save_block() keep looping until there are dirty pages available? - Michael