2010/6/2 Anthony Liguori <aligu...@linux.vnet.ibm.com>: > On 06/01/2010 11:18 AM, Yoshiaki Tamura wrote: >> >> 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? >> > > I wouldn't think so. With threads, you've got to acquire locks and that > lock acquisition can be a source of significant latency. By blocking in > select, you've got a straight dispatch path. > > Really, we'd get 99% of the way there just focusing on live loading of ram. > There's really no need to make the final stage of migration live. > >> 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. >> > > Unless I'm mistaken, the thread patches you've posted make no attempt at > addressing the problem of locking. I believe that properly handling locking > would result in the patch series increasing in size and complexity rather > significantly. > > I think the simpler approach is to implement a state machine for ram > loading.
OK. Making ram loading to be selectable seems to be a good start point. Thanks, Yoshi > > Regards, > > Anthony Liguori > >> 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(-) >>>> >>>> >>>> >>> >>> >>> > > >