* Peter Xu (pet...@redhat.com) wrote: > On Wed, Feb 28, 2018 at 05:43:50PM +0000, Dr. David Alan Gilbert wrote: > > * Peter Xu (pet...@redhat.com) 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 / dgilb...@redhat.com / Manchester, UK
