qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v3 0/7] support dirtyrate at the granualrity of vcpu


From: Hyman
Subject: Re: [PATCH v3 0/7] support dirtyrate at the granualrity of vcpu
Date: Mon, 7 Jun 2021 09:24:28 +0800
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

cc Chuan Zheng <zhengchuan@huawei.com>

在 2021/6/7 9:11, huangy81@chinatelecom.cn 写道:
From: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>

v3:
- pick up "migration/dirtyrate: make sample page count configurable" to
   make patchset apply master correctly

v2:
- rebase to "migration/dirtyrate: make sample page count configurable"

- rename "vcpu" to "per_vcpu" to show the per-vcpu method

- squash patch 5/6 into a single one, squash patch 1/2 also

- pick up "hmp: Add "calc_dirty_rate" and "info dirty_rate" cmds"

- make global_dirty_log a bitmask to make sure both migration and dirty
   could not intefer with each other

- add memory free callback to prevent memory leaking

the most different of v2 fron v1 is that we make the global_dirty_log a
bitmask. the reason is dirty rate measurement may start or stop dirty
logging during calculation. this conflict with migration because stop
dirty log make migration leave dirty pages out then that'll be a
problem.

make global_dirty_log a bitmask can let both migration and dirty
rate measurement work fine. introduce GLOBAL_DIRTY_MIGRATION and
GLOBAL_DIRTY_DIRTY_RATE to distinguish what current dirty log aims
for, migration or dirty rate.
all references to global_dirty_log should be untouched because any bit
set there should justify that global dirty logging is enabled.

Please review, thanks !

v1:

Since the Dirty Ring on QEMU part has been merged recently, how to use
this feature is under consideration.

In the scene of migration, it is valuable to provide a more accurante
interface to track dirty memory than existing one, so that the upper
layer application can make a wise decision, or whatever. More
importantly,
dirtyrate info at the granualrity of vcpu could provide a possibility to
make migration convergent by imposing restriction on vcpu. With Dirty
Ring, we can calculate dirtyrate efficiently and cheaply.

The old interface implemented by sampling pages, it consumes cpu
resource, and the larger guest memory size become, the more cpu resource
it consumes, namely, hard to scale. New interface has no such drawback.

Please review, thanks !

Best Regards !

Hyman Huang(黄勇) (6):
   migration/dirtyrate: make sample page count configurable
   KVM: introduce dirty_pages and kvm_dirty_ring_enabled
   migration/dirtyrate: add per-vcpu option for calc-dirty-rate
   migration/dirtyrate: adjust struct DirtyRateStat
   memory: make global_dirty_log a bitmask
   migration/dirtyrate: implement dirty-ring dirtyrate calculation

Peter Xu (1):
   hmp: Add "calc_dirty_rate" and "info dirty_rate" cmds

  accel/kvm/kvm-all.c    |   7 +
  hmp-commands-info.hx   |  13 ++
  hmp-commands.hx        |  15 ++
  include/exec/memory.h  |  13 +-
  include/hw/core/cpu.h  |   1 +
  include/monitor/hmp.h  |   2 +
  include/sysemu/kvm.h   |   1 +
  migration/dirtyrate.c  | 347 ++++++++++++++++++++++++++++++++++++++---
  migration/dirtyrate.h  |  27 +++-
  migration/ram.c        |   8 +-
  migration/trace-events |   5 +
  qapi/migration.json    |  38 ++++-
  softmmu/memory.c       |  36 +++--
  13 files changed, 468 insertions(+), 45 deletions(-)




reply via email to

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