From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43809 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNde5-0006ZV-DU for qemu-devel@nongnu.org; Tue, 30 Nov 2010 22:46:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNXG1-0008Ut-C8 for qemu-devel@nongnu.org; Tue, 30 Nov 2010 15:57:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56659) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNXG1-0007KY-39 for qemu-devel@nongnu.org; Tue, 30 Nov 2010 15:57:01 -0500 From: Juan Quintela In-Reply-To: <4CF55D3E.5010400@codemonkey.ws> (Anthony Liguori's message of "Tue, 30 Nov 2010 14:23:26 -0600") References: <20101124104035.GB23493@redhat.com> <4CF46012.2060804@codemonkey.ws> <4CF50410.3080305@codemonkey.ws> <20101130161032.GF20536@redhat.com> <4CF52A09.5080201@codemonkey.ws> <4CF5485F.605@codemonkey.ws> <4CF55D3E.5010400@codemonkey.ws> Date: Tue, 30 Nov 2010 21:56:29 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Re: [PATCH 02/10] Add buffered_file_internal constant List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" Anthony Liguori wrote: > On 11/30/2010 01:15 PM, Juan Quintela wrote: >>>> At the end of the ram_save_live(). This was the reason that I put the >>>> information there. >>>> >>>> for the 24mins stall (I don't have that machine anymore) I had less >>>> "exact" measurements. It was the amount that it "decided" to sent in >>>> the last non-live part of memory migration. With the stalls& zero page >>>> account, we just got to the point where we had basically infinity speed. >>>> >>>> >>> That's not quite guest visible. >>> >> Humm, guest don't answer in 24mins >> monitor don't answer in 24mins >> ping don't answer in 24mins >> >> are you sure that this is not visible? Bug report put that guest had >> just died, it was me who waited to see that it took 24mins to end. >> > > I'm extremely sceptical that any of your patches would address this > problem. Even if you had to scan every page in a 400GB guest, it > would not take 24 minutes. Something is not quite right here. > > 24 minutes suggests that there's another problem that is yet to be > identified. I haven't tested the lastest versions of the patches sent to the list, but a previous version fixed that problem. If I get my hands on the machine will try to reproduce the problem and measure things. Later, Juan.