Paolo Bonzini <pbonz...@redhat.com> wrote:
> 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.
will get some general documentation in /doc/.
Basically what we had on the only stream was:
{[page header][page]}+
And we moved to:
{[page header]+[where to receive]}: on the principal stream
[page]+: on the rest of the multifd
All nicely aligned and so.
My understanding is that we could optimize the receiving with splice to
not even touch userspace? (that part is not done). That was the reason
why I didn't want to put header's footers there. As the headers are so
small compared with the pages payload, the transmission of them should
be lost on the noise, no?
Later, Juan.
