From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Li, Liang Z" Subject: RE: [RFC Design Doc]Speed up live migration by skipping free pages Date: Tue, 19 Apr 2016 02:20:57 +0000 Message-ID: References: <20160324165530-mutt-send-email-mst@redhat.com> <20160324175503-mutt-send-email-mst@redhat.com> <20160324181031-mutt-send-email-mst@redhat.com> <20160324174933.GA11662@work-vm> <20160418142704-mutt-send-email-mst@redhat.com> <20160418183257-mutt-send-email-mst@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Cc: "Dr. David Alan Gilbert" , Wei Yang , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "linux-kernel@vger.kenel.org" , "pbonzini@redhat.com" , "rth@twiddle.net" , "ehabkost@redhat.com" , "amit.shah@redhat.com" , "quintela@redhat.com" , "mohan_parthasarathy@hpe.com" , "jitendra.kolhe@hpe.com" , "simhan@hpe.com" , "rkagan@virtuozzo.com" , "riel@redhat.com" To: "Michael S. Tsirkin" Return-path: Received: from mga09.intel.com ([134.134.136.24]:7064 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751943AbcDSCVD convert rfc822-to-8bit (ORCPT ); Mon, 18 Apr 2016 22:21:03 -0400 In-Reply-To: <20160418183257-mutt-send-email-mst@redhat.com> Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: > > > > I am now working on how to benefit post-copy by skipping the free > > > > pages, and I remember you have said we should let the destination > > > > know the info of free pages so as to avoid request the free pages > > > > from the > > > source. > > > > > > > > We have two solutions: > > > > > > > > a. send the migration dirty page bitmap to destination before post > > > > copy start, so the destination can decide whether to request the > > > > pages or place zero pages by checking the migration dirty page > > > > bitmap. The advantage is that we can avoid sending the free pages. > > > > the disadvantage is that we have to send extra data to destination. > > > > > > > > b. Check the page request on the source side, if it's not a dirty > > > > page, send a zero page header to the destination. > > > > > > > > What's your opinion about them? > > > > > > > > Liang > > > > > > > > > > Both are ad-hoc solutions imho. > > > > > > c. put the bitmap in a ramblock, check it on destination before > > > requesting pages. > > > > > > This way it's migrated on-demand. > > > > > Hi MST, > > > > I think you mean putting the free page bitmap in a ramblock. Right? > > If some of the free pages become dirty after updating the free page > > bitmap, and these pages are discarded by destination, how can we > > distinguish these discarded pages with the free pages? > > > > Could you elaborate how it works? > > > > Thanks! > > Liang > > Maybe I'm confused - IIUC it's postcopy so VM is running on destination, if > page is dirty it was modified there so we don't need to get it from source. > The current post-copy is implemented as pre-copy plus post-copy, there is a stage that the source told the destination to discard the newly dirty pages before vm start to run on destination. I don't think the free page bitmap will help, we need a dirty page bitmap. The dirty page bitmap should not be put in a ramblock, it does not belong to guest. > But really I agree with David here - at step 1 just ignore post-copy, don't > special-case it, even if it becomes slower with your patch. > Think about it later. > Yes, we can simply ignore the free page if post-copy is enabled. Think about it now will make my work easier :) Thanks! Liang > > > > > > > -- > > > MST > > > -- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51061) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asLHr-0003h9-Ht for qemu-devel@nongnu.org; Mon, 18 Apr 2016 22:21:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1asLHm-0001Yw-JR for qemu-devel@nongnu.org; Mon, 18 Apr 2016 22:21:11 -0400 Received: from mga11.intel.com ([192.55.52.93]:19849) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asLHm-0001Yc-8w for qemu-devel@nongnu.org; Mon, 18 Apr 2016 22:21:06 -0400 From: "Li, Liang Z" Date: Tue, 19 Apr 2016 02:20:57 +0000 Message-ID: References: <20160324165530-mutt-send-email-mst@redhat.com> <20160324175503-mutt-send-email-mst@redhat.com> <20160324181031-mutt-send-email-mst@redhat.com> <20160324174933.GA11662@work-vm> <20160418142704-mutt-send-email-mst@redhat.com> <20160418183257-mutt-send-email-mst@redhat.com> In-Reply-To: <20160418183257-mutt-send-email-mst@redhat.com> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: "Dr. David Alan Gilbert" , Wei Yang , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "linux-kernel@vger.kenel.org" , "pbonzini@redhat.com" , "rth@twiddle.net" , "ehabkost@redhat.com" , "amit.shah@redhat.com" , "quintela@redhat.com" , "mohan_parthasarathy@hpe.com" , "jitendra.kolhe@hpe.com" , "simhan@hpe.com" , "rkagan@virtuozzo.com" , "riel@redhat.com" > > > > I am now working on how to benefit post-copy by skipping the free > > > > pages, and I remember you have said we should let the destination > > > > know the info of free pages so as to avoid request the free pages > > > > from the > > > source. > > > > > > > > We have two solutions: > > > > > > > > a. send the migration dirty page bitmap to destination before post > > > > copy start, so the destination can decide whether to request the > > > > pages or place zero pages by checking the migration dirty page > > > > bitmap. The advantage is that we can avoid sending the free pages. > > > > the disadvantage is that we have to send extra data to destination. > > > > > > > > b. Check the page request on the source side, if it's not a dirty > > > > page, send a zero page header to the destination. > > > > > > > > What's your opinion about them? > > > > > > > > Liang > > > > > > > > > > Both are ad-hoc solutions imho. > > > > > > c. put the bitmap in a ramblock, check it on destination before > > > requesting pages. > > > > > > This way it's migrated on-demand. > > > > > Hi MST, > > > > I think you mean putting the free page bitmap in a ramblock. Right? > > If some of the free pages become dirty after updating the free page > > bitmap, and these pages are discarded by destination, how can we > > distinguish these discarded pages with the free pages? > > > > Could you elaborate how it works? > > > > Thanks! > > Liang >=20 > Maybe I'm confused - IIUC it's postcopy so VM is running on destination, = if > page is dirty it was modified there so we don't need to get it from sourc= e. >=20 The current post-copy is implemented as pre-copy plus post-copy, there is a= stage that the source told the destination to discard the newly dirty pages befo= re vm start to run on destination. I don't think the free page bitmap will help, we nee= d a dirty page bitmap. The dirty page bitmap should not be put in a ramblock, it does not = belong to guest. > But really I agree with David here - at step 1 just ignore post-copy, don= 't > special-case it, even if it becomes slower with your patch. > Think about it later. >=20 Yes, we can simply ignore the free page if post-copy is enabled. Think abo= ut it now will make my work easier :) Thanks! Liang > > > > > > > -- > > > MST > > > --