* Bohdan Trach (bohdan.tr...@mailbox.tu-dresden.de) 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 / dgilb...@redhat.com / Manchester, UK > > -- > With best regards, > Bohdan Trach -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
