| Message ID | 1598669577-76914-1-git-send-email-zhengchuan@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | *** A Method for evaluating dirty page rate *** | expand |
Trying to think like a control plane developer and user (of which I am neither) raised some questions about the overall interface provided here. If everyone else is happy with the current interface, then I'll shut up :-) It seems like it should be possible to query the last measured dirty rate at any time. In particular, it should be possible to query the value before any rate has been measured (either returning an error, or if that is unpalatable perhaps a result with a zero interval to indicate "this data isn't useful"), but also *during* a subsequent measurement period. That is, the result of the previous measurement should always be available on demand and a measurement becomes "current" when it completes. Given that we allow the caller to specify the measurement interval, some callers might specify a long period. As only one measurement can be taken at a time, a long running measurement rules out taking a short measurement. That's probably okay, but does lead me to wonder whether the API should include a mechanism allowing the cancellation of an in-progress measurement. dme.
On 2020/8/31 17:05, David Edmondson wrote: > Trying to think like a control plane developer and user (of which I am > neither) raised some questions about the overall interface provided > here. If everyone else is happy with the current interface, then I'll > shut up :-) > > It seems like it should be possible to query the last measured dirty > rate at any time. In particular, it should be possible to query the > value before any rate has been measured (either returning an error, or > if that is unpalatable perhaps a result with a zero interval to indicate > "this data isn't useful"), but also *during* a subsequent measurement > period. > Hi, Thank you for your review. For now, i. if we query the value before any rate has been measured, it will return unstarted, and dirtyrate will return -1. {"return":{"status":"unstarted","dirty-rate":-1,"start-time":0,"calc-time":0},"id":"libvirt-14"} ii.if we specify the measurement interval like -1 or 61, it will return error {"id":"libvirt-13","error":{"class":"GenericError","desc":"calc-time is out of range[1, 60]."}} iii. We can query the last measured dirty rate at any time now as you expected in last patch version with returning the measurement timestamp and calc-time. If i have missed some other scenes, please let me know:) > That is, the result of the previous measurement should always be > available on demand and a measurement becomes "current" when it > completes. > > Given that we allow the caller to specify the measurement interval, some > callers might specify a long period. As only one measurement can be > taken at a time, a long running measurement rules out taking a short > measurement. That's probably okay, but does lead me to wonder whether > the API should include a mechanism allowing the cancellation of an > in-progress measurement. That's why we restrict the maximum time to 60s, i think this is enough and also not too long for user to observe the average dirty rate. I think it is may a little expensive and hardly used to implement cancellation mechanism. On the other hand, users could call several times with the measurement interval like 1s, to improve its accuracy otherwise observe a long time. > > dme. >
On Monday, 2020-08-31 at 17:55:39 +08, Zheng Chuan wrote: > On 2020/8/31 17:05, David Edmondson wrote: >> Trying to think like a control plane developer and user (of which I am >> neither) raised some questions about the overall interface provided >> here. If everyone else is happy with the current interface, then I'll >> shut up :-) >> >> It seems like it should be possible to query the last measured dirty >> rate at any time. In particular, it should be possible to query the >> value before any rate has been measured (either returning an error, or >> if that is unpalatable perhaps a result with a zero interval to indicate >> "this data isn't useful"), but also *during* a subsequent measurement >> period. >> > Hi, Thank you for your review. > > For now, > i. if we query the value before any rate has been measured, it will return unstarted, > and dirtyrate will return -1. > {"return":{"status":"unstarted","dirty-rate":-1,"start-time":0,"calc-time":0},"id":"libvirt-14"} > > ii.if we specify the measurement interval like -1 or 61, it will return error > {"id":"libvirt-13","error":{"class":"GenericError","desc":"calc-time is out of range[1, 60]."}} > > iii. We can query the last measured dirty rate at any time now as you expected in last patch version > with returning the measurement timestamp and calc-time. > > If i have missed some other scenes, please let me know:) No, I think that you have everything. My aim was to see if other people agreed with the usage scenarios. >> That is, the result of the previous measurement should always be >> available on demand and a measurement becomes "current" when it >> completes. >> >> Given that we allow the caller to specify the measurement interval, some >> callers might specify a long period. As only one measurement can be >> taken at a time, a long running measurement rules out taking a short >> measurement. That's probably okay, but does lead me to wonder whether >> the API should include a mechanism allowing the cancellation of an >> in-progress measurement. > > That's why we restrict the maximum time to 60s, i think this is enough and also > not too long for user to observe the average dirty rate. > I think it is may a little expensive and hardly used to implement cancellation mechanism. > > On the other hand, users could call several times with the measurement interval > like 1s, to improve its accuracy otherwise observe a long time. Understood. dme.
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"}' 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] 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 get_sample_page_period() 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 | 436 +++++++++++++++++++++++++++++++++++++++++++++++++ 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, 593 insertions(+), 11 deletions(-) create mode 100644 migration/dirtyrate.c create mode 100644 migration/dirtyrate.h