From: Fabiano Rosas <farosas@suse.de>
To: Peter Xu <peterx@redhat.com>, qemu-devel@nongnu.org
Cc: peterx@redhat.com, Juraj Marcin <jmarcin@redhat.com>,
Julia Suvorova <jusual@redhat.com>,
Prasad Pandit <ppandit@redhat.com>
Subject: Re: [PATCH 00/16] migration: Switchover phase refactoring
Date: Wed, 15 Jan 2025 13:49:36 -0300 [thread overview]
Message-ID: <878qrcf2e7.fsf@suse.de> (raw)
In-Reply-To: <20250114230746.3268797-1-peterx@redhat.com>
Peter Xu <peterx@redhat.com> writes:
> CI: https://gitlab.com/peterx/qemu/-/pipelines/1625266692
> (note: warning is present on rust stuff, but shouldn't be relevant)
>
> This series refactors the migration switchover path quite a bit. I started
> this work initially to measure the JSON writer overhead, but then I decided
> to cleanup the switchover path in general when I am at it altogether, as I
> wanted to do this for a long time.
>
> A few major things I tried to do:
>
> - About the JSON writer
>
> Currently, precopy migration always dumps a chunk of data called VM
> description (QEMU_VM_VMDESCRIPTION) for debugging purpose. That is a
> JSON blob explaining all the vmstates dumped in the migration stream.
> QEMU has a machine property suppress-vmdesc deciding whether migration
> will have that JSON chunk included.
>
> Postcopy does not have such JSON dump because postcopy is live session
> and it can't normally be debugged from stream level (e.g. as a streamed
> file).
>
> A tiny problem is we don't yet have a clue on how much cpu cycles we
> need to construct and dump these JSONs even if they're only for
> debugging, and even if suppress-vmdesc=on QEMU will still try to
> construct these JSONs (e.g. also for postcopy).
>
> This series has a few patches just to make sure the JSON blob won't be
> constructed if not needed (either postcopy, or suppress-vmdesc=on). I
> tried to measure the downtime diff with/without these changes, the time
> QEMU takes to construct / dump the JSON blob is still not measurable.
> So I suppose unconditionally having this is ok. Said that, let's still
> have these changes around so we avoid JSON operations if not needed.
>
> - DEVICE migration state
>
> QEMU has a very special DEVICE migration state, that only happens with
> precopy, and only when pause-before-switchover capability is enabled.
> Due to that specialty we can't merge precopy and postcopy code on
> switchover starts, because the state machine will be different.
>
> However after I checked the history and also with libvirt developers,
> this seems unnecessary. So I had one patch making DEVICE state to be
> the "switchover" phase for precopy/postcopy unconditionally. That will
> make the state machine much easier for both modes, meanwhile nothing is
> expected to break with it (but please still shoot if anyone knows /
> suspect something will, or could, break..).
>
> - General cleanups and fixes
>
> Most of the rest changes are random cleanups and fixes in the
> switchover path.
>
> E.g., postcopy_start() has some code that isn't easy to read due to
> some special flags here and there, mostly around the two calls of
> qemu_savevm_state_complete_precopy(). This series will remove most of
> those special treatments here and there.
>
> We could have done something twice in the past in postcopy switchover
> (e.g. I believe we sync CPU twice.. but only happens with postcopy),
> now they should all be sorted out.
>
> And quite some other things hopefully can be separately discussed and
> justified in each patch. After these cleanups, we will be able to have
> an unified entrance for precopy/postcopy on switchover.
>
> Initially I thought this could optimize the downtime slightly, but after
> some tests, it turns out there's no measureable difference, at least in my
> current setup... So let's take this as a cleanup series at least for now,
> and I hope they would still make some sense. Comments welcomed.
>
> Thanks,
>
> Peter Xu (16):
> migration: Remove postcopy implications in should_send_vmdesc()
> migration: Do not construct JSON description if suppressed
> migration: Optimize postcopy on downtime by avoiding JSON writer
> migration: Avoid two src-downtime-end tracepoints for postcopy
> migration: Drop inactivate_disk param in qemu_savevm_state_complete*
> migration: Synchronize all CPU states only for non-iterable dump
> migration: Adjust postcopy bandwidth during switchover
> migration: Adjust locking in migration_maybe_pause()
> migration: Drop cached migration state in migration_maybe_pause()
> migration: Take BQL slightly longer in postcopy_start()
> migration: Notify COMPLETE once for postcopy
> migration: Unwrap qemu_savevm_state_complete_precopy() in postcopy
> migration: Cleanup qemu_savevm_state_complete_precopy()
> migration: Always set DEVICE state
> migration: Merge precopy/postcopy on switchover start
> migration: Trivial cleanup on JSON writer of vmstate_save()
>
> qapi/migration.json | 7 +-
> migration/migration.h | 1 +
> migration/savevm.h | 6 +-
> migration/migration.c | 209 +++++++++++++++++++++++-------------
> migration/savevm.c | 116 ++++++++------------
> migration/vmstate.c | 6 +-
> tests/qtest/libqos/libqos.c | 3 +-
> migration/trace-events | 2 +-
> tests/qemu-iotests/194.out | 1 +
> tests/qemu-iotests/203.out | 1 +
> tests/qemu-iotests/234.out | 2 +
> tests/qemu-iotests/262.out | 1 +
> tests/qemu-iotests/280.out | 1 +
> 13 files changed, 200 insertions(+), 156 deletions(-)
Queued, thanks!
prev parent reply other threads:[~2025-01-15 16:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-14 23:07 [PATCH 00/16] migration: Switchover phase refactoring Peter Xu
2025-01-14 23:07 ` [PATCH 01/16] migration: Remove postcopy implications in should_send_vmdesc() Peter Xu
2025-01-14 23:07 ` [PATCH 02/16] migration: Do not construct JSON description if suppressed Peter Xu
2025-01-14 23:07 ` [PATCH 03/16] migration: Optimize postcopy on downtime by avoiding JSON writer Peter Xu
2025-01-14 23:07 ` [PATCH 04/16] migration: Avoid two src-downtime-end tracepoints for postcopy Peter Xu
2025-01-14 23:07 ` [PATCH 05/16] migration: Drop inactivate_disk param in qemu_savevm_state_complete* Peter Xu
2025-01-14 23:07 ` [PATCH 06/16] migration: Synchronize all CPU states only for non-iterable dump Peter Xu
2025-01-14 23:07 ` [PATCH 07/16] migration: Adjust postcopy bandwidth during switchover Peter Xu
2025-01-14 23:07 ` [PATCH 08/16] migration: Adjust locking in migration_maybe_pause() Peter Xu
2025-01-14 23:07 ` [PATCH 09/16] migration: Drop cached migration state " Peter Xu
2025-01-14 23:07 ` [PATCH 10/16] migration: Take BQL slightly longer in postcopy_start() Peter Xu
2025-01-14 23:07 ` [PATCH 11/16] migration: Notify COMPLETE once for postcopy Peter Xu
2025-01-14 23:07 ` [PATCH 12/16] migration: Unwrap qemu_savevm_state_complete_precopy() in postcopy Peter Xu
2025-01-14 23:07 ` [PATCH 13/16] migration: Cleanup qemu_savevm_state_complete_precopy() Peter Xu
2025-01-14 23:07 ` [PATCH 14/16] migration: Always set DEVICE state Peter Xu
2025-01-14 23:07 ` [PATCH 15/16] migration: Merge precopy/postcopy on switchover start Peter Xu
2025-01-14 23:07 ` [PATCH 16/16] migration: Trivial cleanup on JSON writer of vmstate_save() Peter Xu
2025-01-15 9:12 ` [PATCH 00/16] migration: Switchover phase refactoring Jiri Denemark
2025-01-15 12:55 ` Peter Xu
2025-01-15 16:13 ` Juraj Marcin
2025-01-15 16:49 ` Fabiano Rosas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878qrcf2e7.fsf@suse.de \
--to=farosas@suse.de \
--cc=jmarcin@redhat.com \
--cc=jusual@redhat.com \
--cc=peterx@redhat.com \
--cc=ppandit@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).