migration: fix calculating xbzrle_counters.cache_miss_rate
commitbe8b02edae9aa3a64c1e76cb4067b4bbbb170448
authorXiao Guangrong <xiaoguangrong@tencent.com>
Mon, 3 Sep 2018 09:26:42 +0000 (3 17:26 +0800)
committerDr. David Alan Gilbert <dgilbert@redhat.com>
Wed, 26 Sep 2018 11:21:56 +0000 (26 12:21 +0100)
tree4a8c346a9f6f86f69467285fa4b24fd8c8089278
parent449f91b2c8d2ddf53629d908593f9acf52301b2d
migration: fix calculating xbzrle_counters.cache_miss_rate

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 target guest page
numbers

After that, rename 'iterations' to 'target_page_count' to better reflect
its meaning

Suggested-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Xiao Guangrong <xiaoguangrong@tencent.com>
Message-Id: <20180903092644.25812-3-xiaoguangrong@tencent.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
migration/ram.c