[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 04/14] migration: let incoming side use thread c
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [PATCH 04/14] migration: let incoming side use thread context |
Date: |
Thu, 1 Mar 2018 09:58:24 +0000 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
* Peter Xu (address@hidden) wrote:
> On Wed, Feb 28, 2018 at 05:43:50PM +0000, Dr. David Alan Gilbert wrote:
> > * Peter Xu (address@hidden) wrote:
> > > The old incoming migration is running in main thread and default
> > > gcontext. With the new qio_channel_add_watch_full() we can now let it
> > > run in the thread's own gcontext (if there is one).
> > >
> > > Currently this patch does nothing alone. But when any of the incoming
> > > migration is run in another iothread (e.g., the upcoming migrate-recover
> > > command), this patch will bind the incoming logic to the iothread
> > > instead of the main thread (which may already get page faulted and
> > > hanged).
> >
> > Does this make any difference to the Postcopy listener thread, which
> > takes over reading from the main thread once in postcopy mode?
> > (See savevm.c:postcopy_ram_listen_thread).
>
> It should not. It should only affect when use sends a
> "migrate-recover" with "run-oob=true". The rest should be the same as
> before. And since the postcopy ram load thread is a standalone thread
> with its own initial thread stack (so it's not really in a gmainloop),
> I can hardly tell how that can be affected since it'll always use its
> own thread stack.
OK, I think that's the bit I was worrying about; just since it was
another thread that ended up reading from the fd originally handled
by the incoming side main thread.
Dave
> Or, have I missed anything?
>
> --
> Peter Xu
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-devel] [PATCH 04/14] migration: let incoming side use thread context,
Dr. David Alan Gilbert <=