aboutsummaryrefslogtreecommitdiff
path: root/replay/replay-random.c
diff options
context:
space:
mode:
authorPeter Xu <peterx@redhat.com>2024-02-02 18:28:57 +0800
committerPeter Xu <peterx@redhat.com>2024-02-06 11:05:49 +0800
commit488c84acb465c21b716c3fd14de27ab5ce388c85 (patch)
treecbe33c4168483c98c5356af29389bdca84736f0e /replay/replay-random.c
parent98ea497d8b8a5076be7b6ceb0dcc4a475373eb76 (diff)
migration/multifd: Optimize sender side to be lockless
When reviewing my attempt to refactor send_prepare(), Fabiano suggested we try out with dropping the mutex in multifd code [1]. I thought about that before but I never tried to change the code. Now maybe it's time to give it a stab. This only optimizes the sender side. The trick here is multifd has a clear provider/consumer model, that the migration main thread publishes requests (either pending_job/pending_sync), while the multifd sender threads are consumers. Here we don't have a lot of complicated data sharing, and the jobs can logically be submitted lockless. Arm the code with atomic weapons. Two things worth mentioning: - For multifd_send_pages(): we can use qatomic_load_acquire() when trying to find a free channel, but that's expensive if we attach one ACQUIRE per channel. Instead, keep the qatomic_read() on reading the pending_job flag as we do already, meanwhile use one smp_mb_acquire() after the loop to guarantee the memory ordering. - For pending_sync: it doesn't have any extra data required since now p->flags are never touched, it should be safe to not use memory barrier. That's different from pending_job. Provide rich comments for all the lockless operations to state how they are paired. With that, we can remove the mutex. [1] https://lore.kernel.org/r/87o7d1jlu5.fsf@suse.de Suggested-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240202102857.110210-24-peterx@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>
Diffstat (limited to 'replay/replay-random.c')
0 files changed, 0 insertions, 0 deletions