From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mgfjb-0003Ii-TB for qemu-devel@nongnu.org; Thu, 27 Aug 2009 10:13:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MgfjX-0003BT-59 for qemu-devel@nongnu.org; Thu, 27 Aug 2009 10:13:51 -0400 Received: from [199.232.76.173] (port=52998 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgfjW-0003BC-W2 for qemu-devel@nongnu.org; Thu, 27 Aug 2009 10:13:47 -0400 Received: from mail-qy0-f188.google.com ([209.85.221.188]:52799) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MgfjW-0005Ks-Nu for qemu-devel@nongnu.org; Thu, 27 Aug 2009 10:13:46 -0400 Received: by qyk26 with SMTP id 26so611261qyk.29 for ; Thu, 27 Aug 2009 07:13:45 -0700 (PDT) Message-ID: <4A969496.2070305@codemonkey.ws> Date: Thu, 27 Aug 2009 09:13:42 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [BUG] Regression of exec migration References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pierre Riteau Cc: Chris Lalancette , qemu-devel@nongnu.org Pierre Riteau wrote: > [Sorry Chris, resending without the giant attachments.] > > 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. Without that changeset, it wasn't a live migration. The better way to compare would be to issue stop before doing the migrate and compare that time with the previous time. When a migration is live, it's iterative which means there's more work to do. > only be retried after 100 ms (the next timer tick?). We should be selecting on the fd so it will wait until we can write to it. Regards, Anthony Liguori