From: Juan Quintela <quintela@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: qemu-devel@nongnu.org, Fabiano Rosas <farosas@suse.de>,
Joao Martins <joao.m.martins@oracle.com>
Subject: Re: [PATCH v2 3/5] migration: Add per vmstate downtime tracepoints
Date: Tue, 31 Oct 2023 13:52:07 +0100 [thread overview]
Message-ID: <87msvz7y4o.fsf@secure.mitica> (raw)
In-Reply-To: <20231030163346.765724-4-peterx@redhat.com> (Peter Xu's message of "Mon, 30 Oct 2023 12:33:44 -0400")
Peter Xu <peterx@redhat.com> wrote:
> We have a bunch of savevm_section* tracepoints, they're good to analyze
> migration stream, but not always suitable if someone would like to analyze
> the migration downtime. Two major problems:
>
> - savevm_section* tracepoints are dumping all sections, we only care
> about the sections that contribute to the downtime
>
> - They don't have an identifier to show the type of sections, so no way
> to filter downtime information either easily.
>
> We can add type into the tracepoints, but instead of doing so, this patch
> kept them untouched, instead of adding a bunch of downtime specific
> tracepoints, so one can enable "vmstate_downtime*" tracepoints and get a
> full picture of how the downtime is distributed across iterative and
> non-iterative vmstate save/load.
>
> Note that here both save() and load() need to be traced, because both of
> them may contribute to the downtime. The contribution is not a simple "add
> them together", though: consider when the src is doing a save() of device1
> while the dest can be load()ing for device2, so they can happen
> concurrently.
>
> Tracking both sides make sense because device load() and save() can be
> imbalanced, one device can save() super fast, but load() super slow, vice
> versa. We can't figure that out without tracing both.
>
> Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
queued.
> static
> int qemu_savevm_state_complete_precopy_iterable(QEMUFile *f, bool in_postcopy)
> {
> + int64_t start_ts_each, end_ts_each;
> SaveStateEntry *se;
> int ret;
>
> @@ -1475,6 +1476,8 @@ int qemu_savevm_state_complete_precopy_iterable(QEMUFile *f, bool in_postcopy)
> continue;
> }
> }
> +
> + start_ts_each = qemu_clock_get_us(QEMU_CLOCK_REALTIME);
I still think that:
int64_t start_ts_each = qemu_clock_get_us(QEMU_CLOCK_REALTIME);
> trace_savevm_section_start(se->idstr, se->section_id);
>
> save_section_header(f, se, QEMU_VM_SECTION_END);
> @@ -1486,6 +1489,9 @@ int qemu_savevm_state_complete_precopy_iterable(QEMUFile *f, bool in_postcopy)
> qemu_file_set_error(f, ret);
> return -1;
> }
> + end_ts_each = qemu_clock_get_us(QEMU_CLOCK_REALTIME);
and
int64_t end_ts_each = qemu_clock_get_us(QEMU_CLOCK_REALTIME);
is clearer.
Having to pass the type thing is not "pleasant", but I can't think of a
better way to do it.
Later, Juan.
next prev parent reply other threads:[~2023-10-31 12:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-30 16:33 [PATCH v2 0/5] migration: Downtime tracepoints Peter Xu
2023-10-30 16:33 ` [PATCH v2 1/5] migration: Set downtime_start even for postcopy Peter Xu
2023-10-31 11:38 ` Juan Quintela
2023-10-30 16:33 ` [PATCH v2 2/5] migration: Add migration_downtime_start|end() helpers Peter Xu
2023-10-31 11:39 ` Juan Quintela
2023-10-30 16:33 ` [PATCH v2 3/5] migration: Add per vmstate downtime tracepoints Peter Xu
2023-10-31 12:52 ` Juan Quintela [this message]
2023-10-30 16:33 ` [PATCH v2 4/5] migration: migration_stop_vm() helper Peter Xu
2023-10-31 12:53 ` Juan Quintela
2023-10-30 16:33 ` [PATCH v2 5/5] migration: Add tracepoints for downtime checkpoints Peter Xu
2023-10-31 12:54 ` Juan Quintela
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=87msvz7y4o.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=farosas@suse.de \
--cc=joao.m.martins@oracle.com \
--cc=peterx@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.