qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 18/20] migration: Postcopy preemption enablement


From: Dr. David Alan Gilbert
Subject: Re: [PATCH 18/20] migration: Postcopy preemption enablement
Date: Wed, 23 Feb 2022 09:56:08 +0000
User-agent: Mutt/2.1.5 (2021-12-30)

* Peter Xu (peterx@redhat.com) wrote:
> On Tue, Feb 22, 2022 at 10:52:23AM +0000, Dr. David Alan Gilbert wrote:
> > This does get a bit complicated, which worries me a bit; the code here
> > is already quite complicated.
> 
> Right, it's the way I chose in this patchset on solving this problem.  Not
> sure whether there's any better and easier way.
> 
> For example, we could have used a new thread to send requested pages, and
> synchronize it with the main thread.  But that'll need other kind of
> complexity, and I can't quickly tell whether that'll be better.
> 
> For this single patch, more than half of the complexity comes from the
> ability to interrupt sending one huge page half-way.  It's a bit of a pity
> that, that part will be noop ultimately when with doublemap.

How does that huge-page interruption interact with recovery?
i.e. do we know the start of that hugepage arrived?

> 
> However I kept those only because we don't know when doublemap will be
> ready, not to say, landing.  Meanwhile we can't assume all kernels will
> have doublemap even in the future.

Yeh, if doublemap was already here you could make it a condition of
allowing you to set the option.

Dave

> > (If you repost, there are a few 'channel' variables that could probably
> > be 'unsigned' rather than int)
> 
> That I can do for sure.
> 
> > 
> > Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> 
> Thanks,
> 
> -- 
> Peter Xu
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK




reply via email to

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