From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mia73-0005kw-Uv for qemu-devel@nongnu.org; Tue, 01 Sep 2009 16:37:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mia6z-0005kW-7F for qemu-devel@nongnu.org; Tue, 01 Sep 2009 16:37:57 -0400 Received: from [199.232.76.173] (port=36188 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mia6z-0005kT-3z for qemu-devel@nongnu.org; Tue, 01 Sep 2009 16:37:53 -0400 Received: from lo.gmane.org ([80.91.229.12]:47411) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mia6y-0003Vb-La for qemu-devel@nongnu.org; Tue, 01 Sep 2009 16:37:52 -0400 Received: from list by lo.gmane.org with local (Exim 4.50) id 1Mia6w-0001eI-9e for qemu-devel@nongnu.org; Tue, 01 Sep 2009 22:37:50 +0200 Received: from 143.166.197.6 ([143.166.197.6]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Sep 2009 22:37:50 +0200 Received: from charles by 143.166.197.6 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Sep 2009 22:37:50 +0200 From: Charles Duffy Date: Tue, 01 Sep 2009 15:37:10 -0500 Message-ID: References: <4A969496.2070305@codemonkey.ws> <076B9FA6-C362-47C1-AA8B-70BF147843A6@irisa.fr> <4A96B353.8070600@codemonkey.ws> <65558604-590A-4FD7-877D-E676CE195C7A@irisa.fr> <4A97FA9B.1030401@codemonkey.ws> <1035D85E-79C1-4F45-B4E7-90E74260D43C@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <1035D85E-79C1-4F45-B4E7-90E74260D43C@irisa.fr> Sender: news 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: qemu-devel@nongnu.org Pierre Riteau wrote: > I'm afraid this solves the problem only because you disabled non > blocking operations on the file descriptor, effectively reverting > 907500095851230a480b14bc852c4e49d32cb16d. > See comment inline. Indeed -- fixing this oversight, I'm seeing 2m30s to write an 84mb ramsave. This doesn't seem to square with Anthony's suggestion that the f* functions are to blame; we're still doing an fdopen() call and using f* on incoming migrations, but it's not incoming migrations where we're having performance issues.