From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mgf4Y-00041U-Dr for qemu-devel@nongnu.org; Thu, 27 Aug 2009 09:31:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mgf4T-0003qH-AU for qemu-devel@nongnu.org; Thu, 27 Aug 2009 09:31:25 -0400 Received: from [199.232.76.173] (port=49642 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mgf4T-0003q6-5K for qemu-devel@nongnu.org; Thu, 27 Aug 2009 09:31:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49091) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mgf4S-0005CJ-Ju for qemu-devel@nongnu.org; Thu, 27 Aug 2009 09:31:20 -0400 Message-ID: <4A968AA0.50708@redhat.com> Date: Thu, 27 Aug 2009 15:31:12 +0200 From: Chris Lalancette MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [BUG] Regression of exec migration List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pierre Riteau Cc: qemu-devel@nongnu.org Pierre Riteau wrote: > Commit 907500095851230a480b14bc852c4e49d32cb16d makes exec migration > much slower than before. > I'm running the latest HEAD of qemu, on Debian Lenny 5.0.2. > > I'm migrating a fully booted Linux VM (also running Lenny) with 128MB > of RAM to a file, using the following command: migrate "exec: cat > > vmimage". The resulting file has a size of 57MB (because we save only > what is allocated from the 128MB). > With the current HEAD, it takes from 15 to 40 seconds (it's variable) > to perform the migration to the file. > With commit 907500095851230a480b14bc852c4e49d32cb16d reverted (or just > commenting the "socket_set_nonblock(s->fd);" statement), it takes > about 3 seconds. > > I did a little debugging and it appears that, when in non-blocking > mode, a write to the popen'ed process which fails with EAGAIN (because > cat is busy writing data on disk) will only be retried after 100 ms > (the next timer tick?). > > Attached are two traces of qemu's output with DEBUG_BUFFERED_FILE > defined. > I modified the dprintf macro to print the result of > qemu_get_clock(rt_clock) before the message. > nonblock.log is with an unmodified HEAD while block.log has the > "socket_set_nonblock(s->fd);" statement commented. > Notice the "backend not ready, freezing" messages when nonblock is used. Hm, interesting, thanks for the report. Let me try out a few things and get back to you. -- Chris Lalancette