Re: [PATCH v10 00/12] *** A Method for evaluating dirty page rate ***

[Zheng Chuan]

On 2020/9/17 17:15, Dr. David Alan Gilbert wrote:
> * Chuan Zheng (zhengchuan@huawei.com) wrote:
>> v9 -> v10:
>>     rename find_page_matched as find_block_matched
>>     fix wrong termination condition in find_block_matched
>>     add review-by for patches
>>
>> v8 -> v9:
>>     fix wrong index return of record_ramblock_hash_info
>>     optimize variable name according to review
>>     reset dirty_rate as -1
>>     change returns of compare_page_hash_info to bool
>>
>> v7 -> v8:
>>     add atomic_read for dirtyrate status
>>     add error_report if set dirtyrate state failed
>>     change returns of save_ramblock_hash and record_ramblock_hash_info to 
>> bool
>>     alloc ramblock dirtyinfo array at one time
>>     add review-by for patches
>>
>> v6 -> v7:
>>     fix minior comments and coding style by review
>>     add review-by for patches
>>
>> v5 -> v6:
>>     fix coding style according to review
>>     use TARGET_PAGE_SIZE and TARGET_PAGE_BITS instead of self-defined macros
>>     return start-time and calc-time by qmp command
>>
>> v4 -> v5:
>>     fix git apply failed due to meson-build
>>     add review-by for patches in v3
>>
>> v3 -> v4:
>>     use crc32 to get hash result instead of md5
>>     add DirtyRateStatus to denote calculation status
>>     add some trace_calls to make it easier to debug
>>     fix some comments accroding to review
>>
>> v2 -> v3:
>>     fix size_t compile warning
>>     fix codestyle checked by checkpatch.pl
>>
>> v1 -> v2:
>>     use g_rand_new() to generate rand_buf
>>     move RAMBLOCK_FOREACH_MIGRATABLE into migration/ram.h
>>     add skip_sample_ramblock to filter sampled ramblock
>>     fix multi-numa vm coredump when query dirtyrate
>>     rename qapi interface and rename some structures and functions
>>     succeed to compile by appling each patch
>>     add test for migrating vm
>>
>> Sometimes it is neccessary to evaluate dirty page rate before migration.
>> Users could decide whether to proceed migration based on the evaluation
>> in case of vm performance loss due to heavy workload.
>> Unlikey simulating dirtylog sync which could do harm on runnning vm,
>> we provide a sample-hash method to compare hash results for samping page.
>> In this way, it would have hardly no impact on vm performance.
>>
>> Evaluate the dirtypage rate both on running and migration vm.
>> The VM specifications for migration are as follows:
>> - VM use 4-K page;
>> - the number of VCPU is 32;
>> - the total memory is 32Gigabit;
>> - use 'mempress' tool to pressurize VM(mempress 4096 1024);
>> - migration bandwidth is 1GB/s
>>
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> |                      |  running  |                  migrating              
>>              |
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> | no mempress          |   4MB/s   |          8MB/s      (migrated success)  
>>              |
>> -------------------------------------------------------------------------------------------
>> | mempress 4096 1024   |  1060MB/s |     456MB/s ~ 1142MB/s (cpu throttle 
>> triggered)      |
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> | mempress 4096 4096   |  4114MB/s |     688MB/s ~ 4132MB/s (cpu throttle 
>> triggered)      |
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> Test dirtyrate by qmp command like this:
>> 1.  virsh qemu-monitor-command [vmname] '{"execute":"calc-dirty-rate", 
>> "arguments": {"calc-time": [sleep-time]}}'; 
>> 2.  sleep specific time which is a bit larger than sleep-time
>> 3.  virsh qemu-monitor-command [vmname] '{"execute":"query-dirty-rate"}'
> 
> Thanks; it looks like we have a full set of reviews; I'll try and add
> this for the next migration pull.
> 
>> The qmp command returns like this:
>> {"return":{"status":"measured","dirty-rate":374,"start-time":3718293,"calc-time":1},"id":"libvirt-15"}
>>
>> Further test dirtyrate by libvirt api like this:
>> virsh getdirtyrate [vmname] [sleep-time]
> 
> So do you have some libvirt patches you're going to post?
> 
> Dave
> 

Hi, Dave.

Yes, libvirt(including libvirt-python) interface will come after this qemu 
series patch:)

>> Chuan Zheng (12):
>>   migration/dirtyrate: setup up query-dirtyrate framwork
>>   migration/dirtyrate: add DirtyRateStatus to denote calculation status
>>   migration/dirtyrate: Add RamblockDirtyInfo to store sampled page info
>>   migration/dirtyrate: Add dirtyrate statistics series functions
>>   migration/dirtyrate: move RAMBLOCK_FOREACH_MIGRATABLE into ram.h
>>   migration/dirtyrate: Record hash results for each sampled page
>>   migration/dirtyrate: Compare page hash results for recorded sampled
>>     page
>>   migration/dirtyrate: skip sampling ramblock with size below
>>     MIN_RAMBLOCK_SIZE
>>   migration/dirtyrate: Implement set_sample_page_period() and
>>     is_sample_period_valid()
>>   migration/dirtyrate: Implement calculate_dirtyrate() function
>>   migration/dirtyrate: Implement
>>     qmp_cal_dirty_rate()/qmp_get_dirty_rate() function
>>   migration/dirtyrate: Add trace_calls to make it easier to debug
>>
>>  migration/dirtyrate.c  | 426 
>> +++++++++++++++++++++++++++++++++++++++++++++++++
>>  migration/dirtyrate.h  |  70 ++++++++
>>  migration/meson.build  |   2 +-
>>  migration/ram.c        |  11 +-
>>  migration/ram.h        |  10 ++
>>  migration/trace-events |   8 +
>>  qapi/migration.json    |  67 ++++++++
>>  7 files changed, 583 insertions(+), 11 deletions(-)
>>  create mode 100644 migration/dirtyrate.c
>>  create mode 100644 migration/dirtyrate.h
>>
>> -- 
>> 1.8.3.1
>>