From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47425 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsmLl-0007EC-7Y for qemu-devel@nongnu.org; Thu, 24 Feb 2011 20:20:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PsmLj-0001cd-Qf for qemu-devel@nongnu.org; Thu, 24 Feb 2011 20:20:05 -0500 Received: from mail-wy0-f173.google.com ([74.125.82.173]:46821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PsmLj-0001cX-Fl for qemu-devel@nongnu.org; Thu, 24 Feb 2011 20:20:03 -0500 Received: by wyb29 with SMTP id 29so1217510wyb.4 for ; Thu, 24 Feb 2011 17:20:02 -0800 (PST) MIME-Version: 1.0 Sender: tamura.yoshiaki@gmail.com In-Reply-To: References: <83ec39769be88d8e9916e2180830765c722eebaa.1298421307.git.quintela@redhat.com> Date: Fri, 25 Feb 2011 10:20:01 +0900 Message-ID: Subject: Re: [Qemu-devel] Re: [PATCH 22/22] migration: Make state definitions local From: Yoshiaki Tamura Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com Cc: qemu-devel@nongnu.org 2011/2/24 Juan Quintela : > Yoshiaki Tamura wrote: >> 2011/2/23 Juan Quintela : >>> Yoshiaki Tamura wrote: >>>> 2011/2/23 Juan Quintela : > >>>> Although you're right, I would prefer to keep it so that somebody >>>> outside of migration may understand the status in the future if >>>> there are no harms. >>> >>> my plan is to move MigrationState inside migration.c, and then decide >>> what to export/not export. >> >> Well, it may be just a policy, but it's already exported, and I >> would like to keep it unless it bothers your plan. =A0IIUC, I don't >> think it does. >> >>> Next thing to do is move migration to its >>> own thread. =A0Before doing that, I need to know what parts are used/no= t >>> used outside migration.c. =A0Removing it now means that nothing gets to >>> use it without needing a patch. >> >> I've once asked Anthony whether it's possible to make migration >> to different threads, but his answer was no due to hard >> dependency of qemu's internal code, and making migration to >> different threads are bad design. > > I know. =A0But Anthony is seeing the light O:-) I'm with you at making live migration fast, but let me comment a few. > Basically, without an own thread we are not able to: > - do anything else while on incoming migration > =A0(namely using the monitor) It's not true. Just adding fixed headers to buffered file should be enough for that. I've done it for Kemari as you can see this (http://www.osrg.net/kemari/download/kemari-v0.2-fedora11.mov). > - do anything else than migration. =A0We can try hard and let vcpus to > =A0run, but we would still clog the io_thread. > - We are not able to saturate 10Gbit networking (basically we are doing > =A02/3 level of bufferering (depending on how you count). I think current byte-based dirty bitmap for sending rams are responsible for this too. I've converted it to bit-based dirty and made traversing 100x faster. Also bypassing QEMUFile buffer in case of rams would boost to some degrees. Thanks, Yoshi > So, once code is there, I guess we will convince Anthony to commit it. > > Later, Juan. > >