Re: [Qemu-devel] [PATCH v4 30/47] Postcopy: Maintain sentmap and calculate discard

[Dr. David Alan Gilbert]

* David Gibson (address@hidden) wrote:
> On Fri, Oct 03, 2014 at 06:47:36PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <address@hidden>
> > 
> > Where postcopy is preceeded by a period of precopy, the destination will
> > have received pages that may have been dirtied on the source after the
> > page was sent.  The destination must throw these pages away before
> > starting it's CPUs.
> > 
> > Maintain a 'sentmap' of pages that have already been sent.
> > Calculate list of sent & dirty pages
> > Provide helpers on the destination side to discard these.
> 
> I find this one really hard to wrap my head around, and I'm having
> trouble putting my finger on why.

It seems to turn out fairly compact, and a lot of the time the
bitmap we're trying to transfer is very sparse, but seems to be
a little clumpy.

> I do wonder if the "base + tiny bitmap" encodinng for the discard list
> over the wire is the best choice.  It seems to involve a bunch of
> rather tedious code rejigging the bitmap into 32-bit chunks, and a
> bunch of rather hard to follow code moving back and forth between that
> encoding and simple address or page ranges for handling the actual
> discards.  It also involves sending the bit offsets for the start of
> each ram block over the wire, which feels like it should be an
> internal detail.

Yes the fiddling into 32bit chunks is a bit messier than it was originally;
the problem here is that the migration bitmap (for no apparent reason)
uses 'long' so the complexity all comes from having the internal structure
be flexible and wanting not to pass that flexibility onto the wire.

> Would just a simple list of start..end or start/len pairs end up
> simpler overall?  Converting the bitmap used to track it on the
> source into ranges would be a little fiddly, but I suspect less so
> than the code to split into 32-bit pieces.

In the end you have to traverse that bitmap somewhere, since I already
had the data in the form of a bitmap it seemed reasonable to take advantage
of it as a compact representation.

> It might also be a bit more robust against possible future options for
> source host vs. dest host vs. target page size, since the source can
> construct it in terms if its granularity constraints, and destination
> can round each chunk out to its own granularity.

That already happens here as the destination reconsistutes the addresses
from the bitmap.

Dave
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK