From: Fabiano Rosas <farosas@suse.de>
To: Steve Sistare <steven.sistare@oracle.com>, qemu-devel@nongnu.org
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>,
Philippe Mathieu-Daude <philmd@linaro.org>,
Eugenio Perez Martin <eperezma@redhat.com>,
Peter Xu <peterx@redhat.com>, Si-Wei Liu <si-wei.liu@oracle.com>,
Steve Sistare <steven.sistare@oracle.com>
Subject: Re: [RFC V1 2/7] migration: skip dirty memory tracking for cpr
Date: Mon, 12 Aug 2024 15:57:00 -0300 [thread overview]
Message-ID: <87mslhfu2r.fsf@suse.de> (raw)
In-Reply-To: <1720792931-456433-3-git-send-email-steven.sistare@oracle.com>
Steve Sistare <steven.sistare@oracle.com> writes:
> CPR preserves memory in place, so there is no need to track dirty memory.
> By skipping it, CPR can support devices that do not support tracking.
>
> Signed-off-by: Steve Sistare <steven.sistare@oracle.com>
> ---
> system/memory.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/system/memory.c b/system/memory.c
> index b7548bf112..aef584e638 100644
> --- a/system/memory.c
> +++ b/system/memory.c
> @@ -27,6 +27,7 @@
>
> #include "exec/memory-internal.h"
> #include "exec/ram_addr.h"
> +#include "migration/misc.h"
> #include "sysemu/kvm.h"
> #include "sysemu/runstate.h"
> #include "sysemu/tcg.h"
> @@ -2947,6 +2948,11 @@ bool memory_global_dirty_log_start(unsigned int flags, Error **errp)
>
> assert(flags && !(flags & (~GLOBAL_DIRTY_MASK)));
>
> + /* CPR preserves memory in place, so no need to track dirty memory */
> + if (migrate_mode() != MIG_MODE_NORMAL) {
> + return true;
> + }
How this interacts with DIRTY_RATE and DIRTY_LIMIT? The former at least
seems to never overlap with CPR, right? I'm wondering whether this check
would be more appropriate up in ram.c along with the similar
migrate_background_snapshot() check.
(I wish we had made the global_dirty_log_change() function a bit more
flexible. It would have been a nice place to put this and the snapshot
check. Not worth the risk of changing it now...)
Also, not tracking dirty memory implies also not doing the bitmap sync?
We skip it for bg_snapshot, but not for CPR.
> +
> if (vmstate_change) {
> /* If there is postponed stop(), operate on it first */
> postponed_stop_flags &= ~flags;
> @@ -3021,6 +3027,11 @@ static void memory_vm_change_state_handler(void *opaque, bool running,
>
> void memory_global_dirty_log_stop(unsigned int flags)
> {
> + /* CPR preserves memory in place, so no need to track dirty memory */
> + if (migrate_mode() != MIG_MODE_NORMAL) {
> + return;
> + }
> +
> if (!runstate_is_running()) {
> /* Postpone the dirty log stop, e.g., to when VM starts again */
> if (vmstate_change) {
next prev parent reply other threads:[~2024-08-12 18:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-12 14:02 [RFC V1 0/7] Live update: vdpa Steve Sistare
2024-07-12 14:02 ` [RFC V1 1/7] migration: cpr_needed_for_reuse Steve Sistare
2024-07-12 14:02 ` [RFC V1 2/7] migration: skip dirty memory tracking for cpr Steve Sistare
2024-08-12 18:57 ` Fabiano Rosas [this message]
2024-08-14 19:54 ` Steven Sistare
2024-07-12 14:02 ` [RFC V1 3/7] vdpa/cpr: preserve device fd Steve Sistare
2024-07-12 14:02 ` [RFC V1 4/7] vdpa/cpr: kernel interfaces Steve Sistare
2024-07-12 14:02 ` [RFC V1 5/7] vdpa/cpr: use VHOST_NEW_OWNER Steve Sistare
2024-07-12 14:02 ` [RFC V1 6/7] vdpa/cpr: pass shadow parameter to dma functions Steve Sistare
2024-07-12 14:02 ` [RFC V1 7/7] vdpa/cpr: preserve dma mappings Steve Sistare
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=87mslhfu2r.fsf@suse.de \
--to=farosas@suse.de \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=si-wei.liu@oracle.com \
--cc=steven.sistare@oracle.com \
/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).