[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC 14/15] migration: Postcopy preemption on separate channel
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [PATCH RFC 14/15] migration: Postcopy preemption on separate channel |
Date: |
Tue, 8 Feb 2022 11:24:14 +0000 |
User-agent: |
Mutt/2.1.5 (2021-12-30) |
* Peter Xu (peterx@redhat.com) wrote:
> On Thu, Feb 03, 2022 at 05:45:32PM +0000, Dr. David Alan Gilbert wrote:
> > * Peter Xu (peterx@redhat.com) wrote:
> > > This patch enables postcopy-preempt feature.
> > >
> > > It contains two major changes to the migration logic:
> > >
> > > (1) Postcopy requests are now sent via a different socket from precopy
> > > background migration stream, so as to be isolated from very high
> > > page
> > > request delays
> > >
> > > (2) For huge page enabled hosts: when there's postcopy requests, they
> > > can now
> > > intercept a partial sending of huge host pages on src QEMU.
> > >
> > > After this patch, we'll have two "channels" (or say, sockets, because
> > > it's only
> > > supported on socket-based channels) for postcopy: (1) PRECOPY channel
> > > (which is
> > > the default channel that transfers background pages), and (2) POSTCOPY
> > > channel (which only transfers requested pages).
> > >
> > > On the source QEMU, when we found a postcopy request, we'll interrupt the
> > > PRECOPY channel sending process and quickly switch to the POSTCOPY
> > > channel.
> > > After we serviced all the high priority postcopy pages, we'll switch back
> > > to
> > > PRECOPY channel so that we'll continue to send the interrupted huge page
> > > again.
> > > There's no new thread introduced.
> > >
> > > On the destination QEMU, one new thread is introduced to receive page
> > > data from
> > > the postcopy specific socket.
> > >
> > > This patch has a side effect. After sending postcopy pages, previously
> > > we'll
> > > assume the guest will access follow up pages so we'll keep sending from
> > > there.
> > > Now it's changed. Instead of going on with a postcopy requested page,
> > > we'll go
> > > back and continue sending the precopy huge page (which can be intercepted
> > > by a
> > > postcopy request so the huge page can be sent partially before).
> > >
> > > Whether that's a problem is debatable, because "assuming the guest will
> > > continue to access the next page" doesn't really suite when huge pages are
> > > used, especially if the huge page is large (e.g. 1GB pages). So that
> > > locality
> > > hint is much meaningless if huge pages are used.
> > >
> > > If postcopy preempt is enabled, a separate channel is created for it so
> > > that it
> > > can be used later for postcopy specific page requests. On dst node, a
> > > standalone thread is used to receive postcopy requested pages. The
> > > thread is
> > > created along with the ram listen thread during POSTCOPY_LISTEN phase.
> >
> > I think this patch could do with being split into two; the first one that
> > deals with closing/opening channels; and the second that handles the
> > data on the two channels and does the preemption.
>
> Sounds good, I'll give it a shot on the split.
>
> >
> > Another thought is whether, if in the future we allow multifd +
> > postcopy, the multifd code would change - I think it would end up closer
> > to using multiple channels taking different pages on each one.
>
> Right, so potentially the postcopy channels can be multi-threaded too itself.
>
> We've had a quick discussion on irc, just to recap: I didn't reuse multifd
> infra because IMO multifd is designed with below ideas in mind:
>
> (1) Every multifd thread is equal
> (2) Throughput oriented
>
> However I found that postcopy needs something different when they're mixed up
> together with multifd.
>
> Firstly, we will have some channels sending as much as we could where latency
> is not an issue (aka background pages). However it's not suitable for page
> requests, so we could also have channels that are servicing page faults fron
> dst. In short, there're two types of channels/threads we want, and we may
> want
> to treat them differently.
>
> The current model is we only have 1 postcopy channel and 1 precopy channel,
> but
> it should be easier if we want to make it N post + 1 pre base on this series.
It's not clear to me if we need to be able to do N post + M pre, or
whether we have a rule like always at least 1 post, but if there's more
pagefaults in the queue then you can steal all of the pre channels.
> So far all send() is still done in the migration thread so no new sender
> thread
> but 1 more receiver thread only. If we want to grow that 1->N for postcopy
> channels we may want to move that out too just like what we do with multifd.
> Not sure whether there can be something reused around. That's where I haven't
> yet explored, but this series should already share a common piece of code on
> refactoring of things like tmp huge page on dst node to be able to receive
> with
> multiple huge pages.
Right; it makes me think the multifd+postcopy should just use channels.
> This also reminded me that, instead of a new capability, should I simply
> expose
> a parameter "postcopy-channels=N" to CLI so that we can be prepared with multi
> postcopy channels?
I'm not sure we know enough yet about what configuration it would have;
I'd be tempted to just make it work for the user by enabling both
multifd and preemption and then using this new mechanism rather than
having to add yet another parameter.
Dave
> >
> >
> > Do we need to do anything in psotcopy recovery ?
>
> Yes. It's a todo (in the cover letter), if the whole thing looks sane I'll add
> that together in the non-rfc series.
>
> Thanks,
>
> --
> Peter Xu
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK