From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuNzL-0001PU-Ha for qemu-devel@nongnu.org; Thu, 26 Jul 2012 09:20:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SuNzB-0006ZO-Vg for qemu-devel@nongnu.org; Thu, 26 Jul 2012 09:20:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5565) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuNzB-0006ZG-Nf for qemu-devel@nongnu.org; Thu, 26 Jul 2012 09:20:13 -0400 Message-ID: <501143EB.6030504@redhat.com> Date: Thu, 26 Jul 2012 16:19:39 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1343155012-26316-1-git-send-email-quintela@redhat.com> <1343155012-26316-3-git-send-email-quintela@redhat.com> <20120725202048.GA2708@illuin> In-Reply-To: <20120725202048.GA2708@illuin> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 02/27] split MRU ram list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: Paolo Bonzini , ryanh@us.ibm.com, qemu-devel@nongnu.org, Juan Quintela On 07/25/2012 11:20 PM, Michael Roth wrote: > On Tue, Jul 24, 2012 at 08:36:27PM +0200, Juan Quintela wrote: >> From: Paolo Bonzini >> >> Outside the execution threads the normal, non-MRU-ized order of >> the RAM blocks should always be enough. So manage two separate >> lists, which will have separate locking rules. > > One thing I'm noticing is that, prior to this series, we're traversing the > blocks in MRU order for migration. This seems counter-intuitive, as those are > the blocks most likely to get re-dirtied and re-sent, so it make sense to hold > off on sending those till last to reduce the amount of time the running guest > has to invalidate the target's copy of it. > > This isn't as bad as it could be, since we at least don't restart the > loop on every iteration, but it might still make sense to come up with a way > to keep RAMList.blocks roughly in sync with RAMList.blocks_mru, and then > traverse that in reverse order for ram_save_iterate. The fact that we're > switching from the MRU ordering in the current version might be > obscuring performance issues as well, which is probably worth keeping in > mind. > Main memory is the only ram block which matters (the framebuffer a remote second). The others are ROMs. -- error compiling committee.c: too many arguments to function