2010/6/2 Anthony Liguori <aligu...@linux.vnet.ibm.com>: > On 06/01/2010 10:40 AM, Yoshiaki Tamura wrote: >> >> Hi, >> >> This series add threaded tcp incoming migration. Currently, tcp migration >> on >> incoming side is blocked when outgoing has started on the remote side, and >> you >> can't do anything. With this series you can get info of incoming >> migration by >> calling "info migrate" like on outgoing side. Threaded tcp incoming >> migration >> is enable only when --enable-io-thread is set. >> > > I'm much less confident that threading is the answer here. We really would > just need to have asynchronous incoming migration.
You mean, go back to select() in main(), and then call incoming handler each time? Won't it introduce more latency, resulting less throughput? Although threading maybe a big hammer for just getting monitor working, I think using thread for incoming handler may worth if it doesn't heart performance on receiving data. The downside is mutual exclusion, of course... Thanks, Yoshi > > Regards, > > Anthony Liguori > >> This series apply on top of patch from Corentin posted on May 29. >> >> http://www.mail-archive.com/qemu-devel@nongnu.org/msg33830.html >> >> Yoshiaki Tamura (4): >> qemu-thread: add qemu_thread_join(). >> migration-tcp: threaded tcp incoming migration. >> arch_init: calculate transferred bytes at ram_load(). >> migration: add support to print migration info on incoming side. >> >> arch_init.c | 2 + >> migration-tcp.c | 86 >> ++++++++++++++++++++++++++++++++++++++++++++++--------- >> migration.c | 18 +++++++++-- >> migration.h | 2 +- >> qemu-thread.c | 9 ++++++ >> qemu-thread.h | 1 + >> 6 files changed, 99 insertions(+), 19 deletions(-) >> >> > > >