qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v7 35/42] Don't sync dirty bitmaps in postcopy


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH v7 35/42] Don't sync dirty bitmaps in postcopy
Date: Fri, 31 Jul 2015 10:50:46 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

* Amit Shah (address@hidden) wrote:
> On (Tue) 16 Jun 2015 [11:26:48], Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <address@hidden>
> > 
> > Once we're in postcopy the source processors are stopped and memory
> > shouldn't change any more, so there's no need to look at the dirty
> > map.
> > 
> > There are two notes to this:
> >   1) If we do resync and a page had changed then the page would get
> >      sent again, which the destination wouldn't allow (since it might
> >      have also modified the page)
> >   2) Before disabling this I'd seen very rare cases where a page had been
> >      marked dirtied although the memory contents are apparently identical
> 
> I suppose we don't know why.  Any way to send a message to the dest
> with this info, so the dest can print out something?  That'll help in
> debugging.  (I'm suggesting sending a message to the dest, because
> after a migration, we don't ever think of looking at messages on the
> src.  And chances are the dest could blow up after a migration is
> successful because of such "corruption".)

One way perhaps would be to do one more sync at the end, after migration
is apparently finished, but before the socket was closed; that would
detect these changes and you could send a message to the other end.  However,
given that (2) I say that where I'd seen it the page contents were
identical, this could be a false alarm, so we'd need to be careful.
It also doesn't help you find out *why* it happens, since tracing
back from a bit in the migration bitmap to the area of memory
and the thing that marked it dirty is very hard.  The only way to do
that, is to mark the memory as read-only and then get a backtrace
to find out who tried to change it; but you don't want to do
that on a normal build and cause the source to die.

> > Signed-off-by: Dr. David Alan Gilbert <address@hidden>
> > Reviewed-by: David Gibson <address@hidden>
> 
> Reviewed-by: Amit Shah <address@hidden>

Thanks.

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



reply via email to

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