From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49751 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PscSP-00054j-FJ for qemu-devel@nongnu.org; Thu, 24 Feb 2011 09:46:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PscSJ-0005Dp-EY for qemu-devel@nongnu.org; Thu, 24 Feb 2011 09:46:16 -0500 Received: from mail-vw0-f45.google.com ([209.85.212.45]:60568) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PscSJ-0005Dj-AB for qemu-devel@nongnu.org; Thu, 24 Feb 2011 09:46:11 -0500 Received: by vws19 with SMTP id 19so518771vws.4 for ; Thu, 24 Feb 2011 06:46:10 -0800 (PST) Message-ID: <4D666F3C.9050401@codemonkey.ws> Date: Thu, 24 Feb 2011 08:46:20 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 22/22] migration: Make state definitions local References: <83ec39769be88d8e9916e2180830765c722eebaa.1298421307.git.quintela@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com Cc: Yoshiaki Tamura , qemu-devel@nongnu.org On 02/24/2011 06:23 AM, Juan Quintela wrote: > 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. Before doing that, I need to know what parts are used/not >>> used outside migration.c. Removing 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:-) > Let's be very careful about quoting Anthony as he's known to be incoherent 90% of the time :-) I don't quite recall the context of the discussion with Yoshi, but I'm not quite there in terms of advocating that we throw a bucket full of threads at migration. I think we should move the ram migration to another I/O thread that doesn't hold a lock against the main I/O thread. That's all. Regards, Anthony Liguori > 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. > >