From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X7f8X-0005WT-1O for qemu-devel@nongnu.org; Thu, 17 Jul 2014 02:25:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X7f8N-0001sQ-JB for qemu-devel@nongnu.org; Thu, 17 Jul 2014 02:25:48 -0400 Received: from mail-wg0-x22f.google.com ([2a00:1450:400c:c00::22f]:49951) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X7f8N-0001sI-Bc for qemu-devel@nongnu.org; Thu, 17 Jul 2014 02:25:39 -0400 Received: by mail-wg0-f47.google.com with SMTP id b13so1788049wgh.18 for ; Wed, 16 Jul 2014 23:25:38 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <53C76C5D.1090802@redhat.com> Date: Thu, 17 Jul 2014 08:25:33 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1404495717-4239-1-git-send-email-dgilbert@redhat.com> <1404495717-4239-8-git-send-email-dgilbert@redhat.com> <53B7CE18.9020907@redhat.com> <20140716093742.GE2514@work-vm> <53C64AE1.8070805@redhat.com> <20140716115233.GH2514@work-vm> <53C670B9.7030008@redhat.com> <20140716171039.GW2514@work-vm> In-Reply-To: <20140716171039.GW2514@work-vm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 07/46] Return path: Open a return path on QEMUFile for sockets List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, quintela@redhat.com, lilei@linux.vnet.ibm.com, qemu-devel@nongnu.org Il 16/07/2014 19:10, Dr. David Alan Gilbert ha scritto: >>> > > >>> > >Handling it within the migration thread would make it much more complicated >>> > >(which would be bad since it's already complex enough); >> > >> > Ok. I'm not sure why it is more complicated since migration is essentially >> > two-phase, one where the source drives it and one where the source just >> > waits for requests, but I'll trust you on this. :) > It's not as clean a split like that; during the postcopy phase we still do the linear > page scan to send pages before they're requested, so the main migration thread > code keeps going. Ah, right. As I said, I trusted you! ;) >>>>> > >>> Return path - opened by main thread, written by main thread AND postcopy >>>>> > >>> thread (protected by rp_mutex) >>>> > >> >>>> > >>When does the main thread needs to write? >>> > > >>> > >Not much; the only things the main thread currently responds to are the >>> > >ReqAck (ping like) requests; those are turning out to be very useful during debug; >>> > >I've also got the ability for the destination to send a migration result back to the >>> > >source which seems useful to be able to 'fail' early. >> > >> > Why can't this be done in the listener thread? (Thus transforming it into a >> > more general postcopy migration thread; later we could even change incoming >> > migration from a coroutine to a thread). > It depends when the ReqAck is sent; i.e. if it's received when the listener > thread is running and processing the stream then it's the listener thread that > sends the reply. Could the start of the listener thread basically coincide with a handover from the main thread to the listener thread? If so, perhaps you can avoid sending ReqAcks packets before the "start destination" command (which I suppose should move processing of incoming page data from the main thread to the userfaultfd thread). Then the "start destination" command can also change the socket back to blocking. Paolo > However, that's not necessarily a big issue now that you've pointed out that > the destination fd is already running non-blocking. If the worst comes to the > worst I could just disable the ReqAck's in non-debug. >