[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 13/16] migration: Create thread infrastructure f

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 13/16] migration: Create thread infrastructure for multifd recv side
Date: Fri, 17 Mar 2017 17:05:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 17/03/2017 14:02, Dr. David Alan Gilbert wrote:
>>>          case RAM_SAVE_FLAG_MULTIFD_PAGE:
>>>              fd_num = qemu_get_be16(f);
>>> -            if (fd_num != 0) {
>>> -                /* this is yet an unused variable, changed later */
>>> -                fd_num = fd_num;
>>> -            }
>>> +            multifd_recv_page(host, fd_num);
>>>              qemu_get_buffer(f, host, TARGET_PAGE_SIZE);
>>>              break;
>> I still believe this design is a mistake.
> Is it a use of a separate FD carrying all of the flags/addresses that
> you object to?

Yes, it introduces a serialization point unnecessarily, and I don't
believe the rationale that Juan offered was strong enough.

This is certainly true on the receive side, but serialization is not
even necessary on the send side.  Multiple threads can efficiently split
the work among themselves and visit the dirty bitmap without a central

I need to study the code more to understand another issue.  Say you have
a page that is sent to two different threads in two different
iterations, like

    thread 1
      iteration 1: pages 3, 7
    thread 2
      iteration 1: page 3
      iteration 2: page 7

Does the code ensure that all threads wait at the end of an iteration?
Otherwise, thread 2 could process page 7 from iteration 2 before or
while thread 1 processes the same page from iteration 1.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]