| 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 | expand |
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. ....
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?
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;
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(-)