migration/multifd: call multifd_send_sync_main when sending RAM_SAVE_FLAG_EOS
diff mbox series

Message ID 20190612014337.11255-1-richardw.yang@linux.intel.com
State New
Headers show
Series
  • migration/multifd: call multifd_send_sync_main when sending RAM_SAVE_FLAG_EOS
Related show

Commit Message

Wei Yang June 12, 2019, 1:43 a.m. UTC
On receiving RAM_SAVE_FLAG_EOS, multifd_recv_sync_main() is called to
synchronize receive threads. Current synchronization mechanism is to wait
for each channel's sem_sync semaphore. This semaphore is triggered by a
packet with MULTIFD_FLAG_SYNC flag. While in current implementation, we
don't do multifd_send_sync_main() to send such packet when
blk_mig_bulk_active() is true.

This will leads to the receive threads won't notify
multifd_recv_sync_main() by sem_sync. And multifd_recv_sync_main() will
always wait there.

[Note]: normal migration test works, while didn't test the
blk_mig_bulk_active() case. Since not sure how to produce this
situation.

Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
---
 migration/ram.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Juan Quintela June 12, 2019, 10:14 a.m. UTC | #1
Wei Yang <richardw.yang@linux.intel.com> wrote:
> On receiving RAM_SAVE_FLAG_EOS, multifd_recv_sync_main() is called to
> synchronize receive threads. Current synchronization mechanism is to wait
> for each channel's sem_sync semaphore. This semaphore is triggered by a
> packet with MULTIFD_FLAG_SYNC flag. While in current implementation, we
> don't do multifd_send_sync_main() to send such packet when
> blk_mig_bulk_active() is true.
>
> This will leads to the receive threads won't notify
> multifd_recv_sync_main() by sem_sync. And multifd_recv_sync_main() will
> always wait there.
>
> [Note]: normal migration test works, while didn't test the
> blk_mig_bulk_active() case. Since not sure how to produce this
> situation.
>
> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>

Block migration is weird.
Block migration is weird.
....
Wei Yang June 12, 2019, 2:57 p.m. UTC | #2
On Wed, Jun 12, 2019 at 12:14:14PM +0200, Juan Quintela wrote:
>Wei Yang <richardw.yang@linux.intel.com> wrote:
>> On receiving RAM_SAVE_FLAG_EOS, multifd_recv_sync_main() is called to
>> synchronize receive threads. Current synchronization mechanism is to wait
>> for each channel's sem_sync semaphore. This semaphore is triggered by a
>> packet with MULTIFD_FLAG_SYNC flag. While in current implementation, we
>> don't do multifd_send_sync_main() to send such packet when
>> blk_mig_bulk_active() is true.
>>
>> This will leads to the receive threads won't notify
>> multifd_recv_sync_main() by sem_sync. And multifd_recv_sync_main() will
>> always wait there.
>>
>> [Note]: normal migration test works, while didn't test the
>> blk_mig_bulk_active() case. Since not sure how to produce this
>> situation.
>>
>> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
>
>Reviewed-by: Juan Quintela <quintela@redhat.com>
>
>Block migration is weird.
>Block migration is weird.
>....

Block migration means migrate a whole disk?

Patch
diff mbox series

diff --git a/migration/ram.c b/migration/ram.c
index 3354944f39..bd356764ff 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -3458,8 +3458,8 @@  static int ram_save_iterate(QEMUFile *f, void *opaque)
      */
     ram_control_after_iterate(f, RAM_CONTROL_ROUND);
 
-    multifd_send_sync_main();
 out:
+    multifd_send_sync_main();
     qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
     qemu_fflush(f);
     ram_counters.transferred += 8;