[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH v3 0/3] support dirtyrate measurement with dirty bitmap

From: huangy81
Subject: [PATCH v3 0/3] support dirtyrate measurement with dirty bitmap
Date: Thu, 15 Jul 2021 23:51:30 +0800

From: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>

- do not touch cpu_physical_memory_sync_dirty_bitmap

- rename global var DirtyRateIncreasedPages to DirtyRateDirtyPages 
- stat dirty pages in cpu_physical_memory_set_dirty_lebitmap, which
  is on the execution path of memory_global_dirty_log_sync and can
  be used for dirty rate measuring.

the v3 implemention runs well, we could get accurate dirtyrate
as v1 and simplify the implementation heavyly. it do not touch
the any ram_list.dirty_memory[*], so do has no conflict with migraion
at all. 
if migration is running at the same time with dirtyrate measuring,
measuring may reset protection of pages after
memory_global_dirty_log_sync before migration iteration, but it has
no side affect because kvm_log_clear_one_slot can guarantee that
same dirty_bmap in a slot shouldn't be cleared twice.

- drop the DIRTY_MEMORY_DIRTY_RATE dirty bits

- reuse the DIRTY_MEMORY_MIGRATION dirty bits to stat the dirty

- introduce global var DirtyRateIncreasedPages to stat the
  increased dirty pages

- simplify the logic of calculation. skip the 1'round of
  log sync unconditionally

changes of this version are based on Peter's advice,
like the version 1, it is posted for the sake of RFC.
ideally, this patshset may be merged after the commit:
"migration/dirtyrate: implement dirty-ring dirtyrate calculation"

the dirtyrate measurement implemented by page-sampling originally, it
is not accurate in some scenarios, so we have introduced dirty-ring
based dirtyrate measurement(maybe it will be merged soon), it fix the
accuracy of page-sampling, and more importantly, it is at the
granualrity of vcpu.

dirty-ring method can be used when dirty-ring enable, as supplementary,
we introduce dirty-bitmap method to calculating dirtyrate when dirty log
enable, so that we can also get the accurate dirtyrate if needed in the
absence of dirty-ring.

three things has done to implement the measurement:
- introduce a fresh new dirty bits named DIRTY_MEMORY_DIRTY_RATE, which
  is used to store dirty bitmap after fetching it from kvm. why we do
  not reuse the existing DIRTY_MEMORY_MIGRATION dirty bits is we do not
  want to interfere with migration of and let implementation clear, this 
  is also the reason why dirty_memory be split.

  DIRTY_MEMORY_DIRTY_RATE dirty bits will be filled when
  memory_global_dirty_log_sync executed if GLOBAL_DIRTY_DIRTY_RATE bit
  be set in the global_dirty_tracking flag.

- introduce kvm_get_manual_dirty_log_protect function so that we can
  probe the protect caps of kvm when calculating.

- implement dirtyrate measurement with dirty bitmap with following step:
  1. start the dirty log. 

  2. probe the protect cap, if KVM_DIRTY_LOG_INITIALLY_SET enable, skip
     skip the 1'R and do the reset page protection manually, since kvm
     file bitmap with 1 bits if this cap is enabled. 

  3. clear the DIRTY_MEMORY_DIRTY_RATE dirty bits, prepare to store 
     the dirty bitmap.

  4. start memory_global_dirty_log_sync and fetch dirty bitmap from kvm

  5. reap the DIRTY_MEMORY_DIRTY_RATE dirty bits and do the calculation.

this patchset rebases on the commit 
"migration/dirtyrate: implement dirty-ring dirtyrate calculation",
since the above feature has not been merged, so we post this patch
for the sake of RFC. ideally, this patshset may be merged after it.

Please, review, thanks !

Best Regards !

Hyman Huang(黄勇) (3):
  KVM: introduce kvm_get_manual_dirty_log_protect
  memory: introduce DirtyRateDirtyPages and util function
  migration/dirtyrate: implement dirty-bitmap dirtyrate calculation

 accel/kvm/kvm-all.c     |   6 +++
 hmp-commands.hx         |   9 ++--
 include/exec/ram_addr.h |  19 ++++++++
 include/sysemu/kvm.h    |   1 +
 migration/dirtyrate.c   | 118 ++++++++++++++++++++++++++++++++++++++++++++----
 migration/trace-events  |   1 +
 qapi/migration.json     |   6 ++-
 7 files changed, 145 insertions(+), 15 deletions(-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]