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 <pbonz...@redhat.com> >> >> 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
