[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 02/27] split MRU ram list

From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 02/27] split MRU ram list
Date: Thu, 26 Jul 2012 16:19:39 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

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 <address@hidden>
>> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]