From: Peter Xu <peterx@redhat.com>
To: guangrong.xiao@gmail.com
Cc: pbonzini@redhat.com, mst@redhat.com, mtosatti@redhat.com,
qemu-devel@nongnu.org, kvm@vger.kernel.org, dgilbert@redhat.com,
wei.w.wang@intel.com, jiang.biao2@zte.com.cn, eblake@redhat.com,
Xiao Guangrong <xiaoguangrong@tencent.com>
Subject: Re: [Qemu-devel] [PATCH v3 09/10] migration: fix calculating xbzrle_counters.cache_miss_rate
Date: Wed, 8 Aug 2018 14:05:06 +0800 [thread overview]
Message-ID: <20180808060506.GH24415@xz-mi> (raw)
In-Reply-To: <20180807091209.13531-10-xiaoguangrong@tencent.com>
On Tue, Aug 07, 2018 at 05:12:08PM +0800, guangrong.xiao@gmail.com wrote:
> From: Xiao Guangrong <xiaoguangrong@tencent.com>
>
> As Peter pointed out:
> | - xbzrle_counters.cache_miss is done in save_xbzrle_page(), so it's
> | per-guest-page granularity
> |
> | - RAMState.iterations is done for each ram_find_and_save_block(), so
> | it's per-host-page granularity
> |
> | An example is that when we migrate a 2M huge page in the guest, we
> | will only increase the RAMState.iterations by 1 (since
> | ram_find_and_save_block() will be called once), but we might increase
> | xbzrle_counters.cache_miss for 2M/4K=512 times (we'll call
> | save_xbzrle_page() that many times) if all the pages got cache miss.
> | Then IMHO the cache miss rate will be 512/1=51200% (while it should
> | actually be just 100% cache miss).
>
> And he also suggested as xbzrle_counters.cache_miss_rate is the only
> user of rs->iterations we can adapt it to count guest page numbers
>
> After that, rename 'iterations' to 'handle_pages' to better reflect
> its meaning
>
> Suggested-by: Peter Xu <peterx@redhat.com>
> Signed-off-by: Xiao Guangrong <xiaoguangrong@tencent.com>
> ---
> migration/ram.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/migration/ram.c b/migration/ram.c
> index 09be01dca2..bd7c18d1f9 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -300,10 +300,10 @@ struct RAMState {
> uint64_t num_dirty_pages_period;
> /* xbzrle misses since the beginning of the period */
> uint64_t xbzrle_cache_miss_prev;
> - /* number of iterations at the beginning of period */
> - uint64_t iterations_prev;
> - /* Iterations since start */
> - uint64_t iterations;
> + /* total handled pages at the beginning of period */
> + uint64_t handle_pages_prev;
> + /* total handled pages since start */
> + uint64_t handle_pages;
The name is not that straightforward to me. I would think about
"[guest|host]_page_count" or something better, or we just keep the old
naming but with a better comment would be fine too.
> /* number of dirty bits in the bitmap */
> uint64_t migration_dirty_pages;
> /* last dirty_sync_count we have seen */
> @@ -1587,19 +1587,19 @@ uint64_t ram_pagesize_summary(void)
>
> static void migration_update_rates(RAMState *rs, int64_t end_time)
> {
> - uint64_t iter_count = rs->iterations - rs->iterations_prev;
> + uint64_t page_count = rs->handle_pages - rs->handle_pages_prev;
>
> /* calculate period counters */
> ram_counters.dirty_pages_rate = rs->num_dirty_pages_period * 1000
> / (end_time - rs->time_last_bitmap_sync);
>
> - if (!iter_count) {
> + if (!page_count) {
> return;
> }
>
> if (migrate_use_xbzrle()) {
> xbzrle_counters.cache_miss_rate = (double)(xbzrle_counters.cache_miss -
> - rs->xbzrle_cache_miss_prev) / iter_count;
> + rs->xbzrle_cache_miss_prev) / page_count;
> rs->xbzrle_cache_miss_prev = xbzrle_counters.cache_miss;
> }
> }
> @@ -1657,7 +1657,7 @@ static void migration_bitmap_sync(RAMState *rs)
>
> migration_update_rates(rs, end_time);
>
> - rs->iterations_prev = rs->iterations;
> + rs->handle_pages_prev = rs->handle_pages;
>
> /* reset period counters */
> rs->time_last_bitmap_sync = end_time;
> @@ -3209,7 +3209,7 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
> break;
> }
>
> - rs->iterations++;
> + rs->handle_pages += pages;
So it's still counting host pages, is this your intention to only
change the name in the patch?
>
> /* we want to check in the 1st loop, just in case it was the 1st time
> and we had to sync the dirty bitmap.
> --
> 2.14.4
>
Regards,
--
Peter Xu
next prev parent reply other threads:[~2018-08-08 6:05 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-07 9:11 [Qemu-devel] [PATCH v3 00/10] migration: compression optimization guangrong.xiao
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 01/10] migration: do not wait for free thread guangrong.xiao
2018-08-07 13:29 ` Eric Blake
2018-08-08 3:51 ` Peter Xu
2018-08-08 6:20 ` Xiao Guangrong
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 02/10] migration: fix counting normal page for compression guangrong.xiao
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 03/10] migration: introduce save_zero_page_to_file guangrong.xiao
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 04/10] migration: drop the return value of do_compress_ram_page guangrong.xiao
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 05/10] migration: move handle of zero page to the thread guangrong.xiao
2018-08-08 4:39 ` Peter Xu
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 06/10] migration: hold the lock only if it is really needed guangrong.xiao
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 07/10] migration: do not flush_compressed_data at the end of each iteration guangrong.xiao
2018-08-08 4:52 ` Peter Xu
2018-08-08 6:22 ` Xiao Guangrong
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 08/10] migration: handle the error condition properly guangrong.xiao
2018-08-08 5:08 ` Peter Xu
2018-08-08 6:29 ` Xiao Guangrong
2018-08-08 6:56 ` Peter Xu
2018-08-08 7:23 ` Xiao Guangrong
2018-08-08 8:46 ` Peter Xu
2018-08-08 14:11 ` Dr. David Alan Gilbert
2018-08-09 3:08 ` Xiao Guangrong
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 09/10] migration: fix calculating xbzrle_counters.cache_miss_rate guangrong.xiao
2018-08-08 6:05 ` Peter Xu [this message]
2018-08-08 6:36 ` Xiao Guangrong
2018-08-08 6:59 ` Peter Xu
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 10/10] migration: show the statistics of compression guangrong.xiao
2018-08-08 6:12 ` Peter Xu
2018-08-09 3:13 ` Xiao Guangrong
2018-08-09 3:34 ` Peter Xu
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=20180808060506.GH24415@xz-mi \
--to=peterx@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=guangrong.xiao@gmail.com \
--cc=jiang.biao2@zte.com.cn \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=wei.w.wang@intel.com \
--cc=xiaoguangrong@tencent.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).