From: Balamuruhan S <bala24@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: quintela@redhat.com, dgilbert@redhat.com, dgibson@redhat.com,
Balamuruhan S <bala24@linux.vnet.ibm.com>
Subject: [Qemu-devel] [PATCH v3 0/1] migration: calculate expected_downtime with ram_bytes_remaining()
Date: Wed, 25 Apr 2018 12:40:39 +0530 [thread overview]
Message-ID: <20180425071040.25542-1-bala24@linux.vnet.ibm.com> (raw)
V3:
* commit message to be updated with the changes done by the patch since
v1, review comment by David Gibson.
* Included Michael Roth as ``Reported-by:`` for bringing up the concern.
v2:
There is some difference in expected_downtime value due to following
reason,
1. bandwidth and expected_downtime value are calculated in
migration_update_counters() during each iteration from
migration_thread()
2. remaining ram is calculated in qmp_query_migrate() when we actually
call "info migrate"
This v2 patch where bandwidth, expected_downtime and remaining ram are
calculated in migration_update_counters(), retrieve the same value
during
"info migrate". By this approach we get almost close enough value,
(qemu) info migrate
globals:
store-global-state: on
only-migratable: off
send-configuration: on
send-section-footer: on
capabilities: xbzrle: off rdma-pin-all: off auto-converge: off
zero-blocks: off compress: off events: off postcopy-ram: off x-colo: off
release-ram: off block: off return-path: off pause-before-switchover:
off x-multifd: off dirty-bitmaps: off
Migration status: active
total time: 319737 milliseconds
expected downtime: 1054 milliseconds
setup: 16 milliseconds
transferred ram: 3669862 kbytes
throughput: 108.92 mbps
remaining ram: 14016 kbytes
total ram: 8388864 kbytes
duplicate: 2296276 pages
skipped: 0 pages
normal: 910639 pages
normal bytes: 3642556 kbytes
dirty sync count: 249
page size: 4 kbytes
dirty pages rate: 4626 pages
Calculation:
calculated value = (14016 * 8 ) / 108.92 = 1029.452809401 milliseconds
actual value = 1054 milliseconds
since v1:
use ram_bytes_remaining() instead of dirty_pages_rate * page_size to
calculate expected_downtime to be more accurate.
Regards,
Bala
Balamuruhan S (1):
migration: calculate expected_downtime with ram_bytes_remaining()
migration/migration.c | 11 ++++++++---
migration/migration.h | 1 +
2 files changed, 9 insertions(+), 3 deletions(-)
--
2.14.3
next reply other threads:[~2018-04-25 7:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-25 7:10 Balamuruhan S [this message]
2018-04-25 7:10 ` [Qemu-devel] [PATCH v3 1/1] migration: calculate expected_downtime with ram_bytes_remaining() Balamuruhan S
2018-05-01 14:37 ` Balamuruhan S
2018-05-16 13:43 ` Laurent Vivier
2018-05-22 11:33 ` Balamuruhan S
2018-06-08 18:24 ` Laurent Vivier
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=20180425071040.25542-1-bala24@linux.vnet.ibm.com \
--to=bala24@linux.vnet.ibm.com \
--cc=dgibson@redhat.com \
--cc=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.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).