[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
[PATCH 19/20] migration: Postcopy recover with preempt enabled, Peter Xu, 2022/02/16
[PATCH 20/20] tests: Add postcopy preempt test, Peter Xu, 2022/02/16