From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH v2 00/41] postcopy live migration Date: Mon, 04 Jun 2012 20:37:04 +0800 Message-ID: <4FCCABF0.6080907@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, owasserm@redhat.com, quintela@redhat.com, avi@redhat.com, pbonzini@redhat.com, stefanha@gmail.com, dlaor@redhat.com, mdroth@linux.vnet.ibm.com, yoshikawa.takuya@oss.ntt.co.jp, benoit.hudzia@gmail.com, aarcange@redhat.com, t.hirofuchi@aist.go.jp, satoshi.itoh@aist.go.jp To: Isaku Yamahata Return-path: Received: from e34.co.us.ibm.com ([32.97.110.152]:43062 "EHLO e34.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755581Ab2FDMhs (ORCPT ); Mon, 4 Jun 2012 08:37:48 -0400 Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 4 Jun 2012 06:37:47 -0600 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 92F21C40003 for ; Mon, 4 Jun 2012 12:37:42 +0000 (WET) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q54CbH9Z022238 for ; Mon, 4 Jun 2012 06:37:17 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q54Cc6oM022719 for ; Mon, 4 Jun 2012 06:38:07 -0600 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 06/04/2012 05:57 PM, Isaku Yamahata wrote: > After the long time, we have v2. This is qemu part. > The linux kernel part is sent separatedly. > > Changes v1 -> v2: > - split up patches for review > - buffered file refactored > - many bug fixes > Espcially PV drivers can work with postcopy > - optimization/heuristic > > Patches > 1 - 30: refactoring exsiting code and preparation > 31 - 37: implement postcopy itself (essential part) > 38 - 41: some optimization/heuristic for postcopy > > Intro > ===== > This patch series implements postcopy live migration.[1] > As discussed at KVM forum 2011, dedicated character device is used for > distributed shared memory between migration source and destination. > Now we can discuss/benchmark/compare with precopy. I believe there are > much rooms for improvement. > > [1] http://wiki.qemu.org/Features/PostCopyLiveMigration > > > Usage > ===== > You need load umem character device on the host before starting migration. > Postcopy can be used for tcg and kvm accelarator. The implementation depend > on only linux umem character device. But the driver dependent code is split > into a file. > I tested only host page size == guest page size case, but the implementation > allows host page size != guest page size case. > > The following options are added with this patch series. > - incoming part > command line options > -postcopy [-postcopy-flags] > where flags is for changing behavior for benchmark/debugging > Currently the following flags are available > 0: default > 1: enable touching page request > > example: > qemu -postcopy -incoming tcp:0:4444 -monitor stdio -machine accel=kvm > > - outging part > options for migrate command > migrate [-p [-n] [-m]] URI [ []] > -p: indicate postcopy migration > -n: disable background transferring pages: This is for benchmark/debugging > -m: move background transfer of postcopy mode > : The number of forward pages which is sent with on-demand > : The number of backward pages which is sent with > on-demand > > example: > migrate -p -n tcp::4444 > migrate -p -n -m tcp::4444 32 0 > > > TODO > ==== > - benchmark/evaluation. Especially how async page fault affects the result. I don't mean to beat on a dead horse, but I really don't understand the point of postcopy migration other than the fact that it's possible. It's a lot of code and a new ABI in an area where we already have too much difficulty maintaining our ABI. Without a compelling real world case with supporting benchmarks for why we need postcopy and cannot improve precopy, I'm against merging this. Regards, Anthony Liguori