[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL 07/12] migration: Start of multiple fd work
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PULL 07/12] migration: Start of multiple fd work |
Date: |
Tue, 14 Feb 2017 14:37:34 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 |
On 14/02/2017 14:12, Juan Quintela wrote:
>> On 13/02/2017 18:19, Juan Quintela wrote:
>>> + qemu_sem_init(&p->init, 0);
>>> p->quit = false;
>>> + p->c = socket_send_channel_create();
>>> + if (!p->c) {
>>> + error_report("Error creating a send channel");
>>> + exit(0);
>>> + }
>>> snprintf(thread_name, 15, "multifd_send_%d", i);
>>> qemu_thread_create(&p->thread, thread_name, multifd_send_thread, p,
>>> QEMU_THREAD_JOINABLE);
>>> + qemu_sem_wait(&p->init);
>> Why do you need p->init here? Could initialization proceed in parallel
>> for all the threads?
>
> We need to make sure that the send thread number 2 goes to thread number
> 2 on destination. Yes, we could do a more complicated algorithm, but we
> really care so much about this initialization time?
I was wondering if p->init was needed in general, so it would simplify.
But without a design document I cannot really understand the logic---as
I said, I don't really grok the need for RAM_SAVE_FLAG_MULTIFD_PAGE.
Paolo
- [Qemu-devel] [PULL 06/12] migration: Create multifd migration threads, (continued)
[Qemu-devel] [PULL 08/12] migration: Create ram_multifd_page, Juan Quintela, 2017/02/13
[Qemu-devel] [PULL 10/12] migration: Really use multiple pages at a time, Juan Quintela, 2017/02/13
[Qemu-devel] [PULL 12/12] migration: Test new fd infrastructure, Juan Quintela, 2017/02/13
[Qemu-devel] [PULL 09/12] migration: Create thread infrastructure for multifd send side, Juan Quintela, 2017/02/13
Re: [Qemu-devel] [PATCH 00/12] Multifd v4, Peter Maydell, 2017/02/14
Re: [Qemu-devel] [PATCH 00/12] Multifd v4, Paolo Bonzini, 2017/02/14