From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41354 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsaFX-0004mU-5S for qemu-devel@nongnu.org; Thu, 24 Feb 2011 07:24:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PsaFV-0007WA-S6 for qemu-devel@nongnu.org; Thu, 24 Feb 2011 07:24:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PsaFV-0007W0-Hy for qemu-devel@nongnu.org; Thu, 24 Feb 2011 07:24:49 -0500 From: Juan Quintela In-Reply-To: (Yoshiaki Tamura's message of "Thu, 24 Feb 2011 13:19:48 +0900") References: <83ec39769be88d8e9916e2180830765c722eebaa.1298421307.git.quintela@redhat.com> Date: Thu, 24 Feb 2011 13:23:19 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: [PATCH 22/22] migration: Make state definitions local Reply-To: quintela@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yoshiaki Tamura Cc: qemu-devel@nongnu.org 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. IIUC, I don't > think it does. > >> Next thing to do is move migration to its >> own thread. =C2=A0Before doing that, I need to know what parts are used/= not >> used outside migration.c. =C2=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. But Anthony is seeing the light O:-) Basically, without an own thread we are not able to: - do anything else while on incoming migration (namely using the monitor) - do anything else than migration. We can try hard and let vcpus to run, but we would still clog the io_thread. - We are not able to saturate 10Gbit networking (basically we are doing 2/3 level of bufferering (depending on how you count). So, once code is there, I guess we will convince Anthony to commit it. Later, Juan.