mirror of
https://github.com/Motorhead1991/qemu.git
synced 2026-02-23 20:55:05 -07:00
f5f48a7891
Multifd provide a threaded model for processing jobs. On sender side,
there can be two kinds of job: (1) a list of pages to send, or (2) a sync
request.
The sync request is a very special kind of job. It never contains a page
array, but only a multifd packet telling the dest side to synchronize with
sent pages.
Before this patch, both requests use the pending_job field, no matter what
the request is, it will boost pending_job, while multifd sender thread will
decrement it after it finishes one job.
However this should be racy, because SYNC is special in that it needs to
set p->flags with MULTIFD_FLAG_SYNC, showing that this is a sync request.
Consider a sequence of operations where:
- migration thread enqueue a job to send some pages, pending_job++ (0->1)
- [...before the selected multifd sender thread wakes up...]
- migration thread enqueue another job to sync, pending_job++ (1->2),
setup p->flags=MULTIFD_FLAG_SYNC
- multifd sender thread wakes up, found pending_job==2
- send the 1st packet with MULTIFD_FLAG_SYNC and list of pages
- send the 2nd packet with flags==0 and no pages
This is not expected, because MULTIFD_FLAG_SYNC should hopefully be done
after all the pages are received. Meanwhile, the 2nd packet will be
completely useless, which contains zero information.
I didn't verify above, but I think this issue is still benign in that at
least on the recv side we always receive pages before handling
MULTIFD_FLAG_SYNC. However that's not always guaranteed and just tricky.
One other reason I want to separate it is using p->flags to communicate
between the two threads is also not clearly defined, it's very hard to read
and understand why accessing p->flags is always safe; see the current impl
of multifd_send_thread() where we tried to cache only p->flags. It doesn't
need to be that complicated.
This patch introduces pending_sync, a separate flag just to show that the
requester needs a sync. Alongside, we remove the tricky caching of
p->flags now because after this patch p->flags should only be used by
multifd sender thread now, which will be crystal clear. So it is always
thread safe to access p->flags.
With that, we can also safely convert the pending_job into a boolean,
because we don't support >1 pending jobs anyway.
Always use atomic ops to access both flags to make sure no cache effect.
When at it, drop the initial setting of "pending_job = 0" because it's
always allocated using g_new0().
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20240202102857.110210-7-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
|
||
|---|---|---|
| .. | ||
| block-dirty-bitmap.c | ||
| block.c | ||
| block.h | ||
| channel-block.c | ||
| channel-block.h | ||
| channel.c | ||
| channel.h | ||
| colo-failover.c | ||
| colo.c | ||
| dirtyrate.c | ||
| dirtyrate.h | ||
| exec.c | ||
| exec.h | ||
| fd.c | ||
| fd.h | ||
| file.c | ||
| file.h | ||
| global_state.c | ||
| meson.build | ||
| migration-hmp-cmds.c | ||
| migration-stats.c | ||
| migration-stats.h | ||
| migration.c | ||
| migration.h | ||
| multifd-zlib.c | ||
| multifd-zstd.c | ||
| multifd.c | ||
| multifd.h | ||
| options.c | ||
| options.h | ||
| page_cache.c | ||
| page_cache.h | ||
| postcopy-ram.c | ||
| postcopy-ram.h | ||
| qemu-file.c | ||
| qemu-file.h | ||
| ram-compress.c | ||
| ram-compress.h | ||
| ram.c | ||
| ram.h | ||
| rdma.c | ||
| rdma.h | ||
| savevm.c | ||
| savevm.h | ||
| socket.c | ||
| socket.h | ||
| target.c | ||
| threadinfo.c | ||
| threadinfo.h | ||
| tls.c | ||
| tls.h | ||
| trace-events | ||
| trace.h | ||
| vmstate-types.c | ||
| vmstate.c | ||
| xbzrle.c | ||
| xbzrle.h | ||
| yank_functions.c | ||
| yank_functions.h | ||