From: Anthony Liguori <aliguori@linux.vnet.ibm.com>
To: Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH 0/4] Threaded tcp incoming migration.
Date: Tue, 01 Jun 2010 11:22:32 -0500 [thread overview]
Message-ID: <4C0533C8.1080309@linux.vnet.ibm.com> (raw)
In-Reply-To: <AANLkTinvpMwX9MegUlKsXG2ZdoIS9NuzStnss-z6jac6@mail.gmail.com>
On 06/01/2010 11:18 AM, Yoshiaki Tamura wrote:
> 2010/6/2 Anthony Liguori<aliguori@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.
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(-)
>>>
>>>
>>>
>>
>>
>>
next prev parent reply other threads:[~2010-06-01 16:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-01 15:40 [Qemu-devel] [PATCH 0/4] Threaded tcp incoming migration Yoshiaki Tamura
2010-06-01 15:40 ` [Qemu-devel] [PATCH 1/4] qemu-thread: add qemu_thread_join() Yoshiaki Tamura
2010-06-01 15:40 ` [Qemu-devel] [PATCH 2/4] migration-tcp: threaded tcp incoming migration Yoshiaki Tamura
2010-06-01 16:01 ` [Qemu-devel] " Anthony Liguori
2010-06-01 16:23 ` Yoshiaki Tamura
2010-06-01 16:28 ` Anthony Liguori
2010-06-01 16:46 ` Yoshiaki Tamura
2010-06-01 15:40 ` [Qemu-devel] [PATCH 3/4] arch_init: calculate transferred bytes at ram_load() Yoshiaki Tamura
2010-06-01 15:40 ` [Qemu-devel] [PATCH 4/4] migration: add support to print migration info on incoming side Yoshiaki Tamura
2010-06-01 15:58 ` [Qemu-devel] Re: [PATCH 0/4] Threaded tcp incoming migration Anthony Liguori
2010-06-01 16:18 ` Yoshiaki Tamura
2010-06-01 16:22 ` Anthony Liguori [this message]
2010-06-01 16:44 ` Yoshiaki Tamura
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C0533C8.1080309@linux.vnet.ibm.com \
--to=aliguori@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=tamura.yoshiaki@lab.ntt.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.