Re: [Qemu-devel] [PATCH RFC 3/3] migration: use checkpoint during migration

[Dr. David Alan Gilbert]

* Bohdan Trach (address@hidden) wrote:
> 
> On 11/17/2015 01:26 PM, Dr. David Alan Gilbert wrote:
> > There are a couple of things I don't understand about this:
> >   1) How does the source fill it's hashes table?  Is it just given the same
> >      dump file as the destination?
> >   2) Why does RAM_SAVE_FLAG_PAGE_HASH exist; if you're sending the full page
> >      to the destination, why do we also send the hash?
> 
> 1. Migration source is assumed to have the same dump file as the
> destination. The design was optimized for the case of ping-pong
> migrations over SAN, where checkpoint file is always available. We
> also have proof-of-concept code that transfers available hashes from
> the migration destination to the source over the network, but it
> didn't make it into these patches.

OK, it's easy with the SAN then.

> 2. We send the hash to avoid hash calculations on the receiving side
> to save some CPU time. This flag can be removed, as I don't think the
> benefits it provides are big.

Why is the hash needed on the destination; if it's a page which the source
has decided isn't in a matching page, what does the destination use the
hash for?

> > I think there's a problem here that given the source is still running it's 
> > CPU and changing
> > memory; it can be writing to the page at the same time, so the page you 
> > send might not
> > match the hash you send;  we're guaranteed to resend the page again if it 
> > was written
> > to, but that still doesn't make these two things match; although as I say 
> > above
> > I'm not sure why SAVE_FLAG_PAGE_HASH exists.
> 
> This is true. In this case, we will just delete the SAVE_FLAG_PAGE_HASH flag.

But how do you know to delete the SAVE_FLAG_PAGE_HASH flag?

Dave

> 
> > --
> > Dr. David Alan Gilbert / address@hidden / Manchester, UK
> 
> -- 
> With best regards,
> Bohdan Trach
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK