[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v6 00/12] *** A Method for evaluating dirty page rate ***
From: |
Zheng Chuan |
Subject: |
Re: [PATCH v6 00/12] *** A Method for evaluating dirty page rate *** |
Date: |
Mon, 31 Aug 2020 17:55:39 +0800 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 |
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.
>
- [PATCH v6 08/12] migration/dirtyrate: skip sampling ramblock with size below MIN_RAMBLOCK_SIZE, (continued)
- [PATCH v6 08/12] migration/dirtyrate: skip sampling ramblock with size below MIN_RAMBLOCK_SIZE, Chuan Zheng, 2020/08/28
- [PATCH v6 05/12] migration/dirtyrate: move RAMBLOCK_FOREACH_MIGRATABLE into ram.h, Chuan Zheng, 2020/08/28
- [PATCH v6 07/12] migration/dirtyrate: Compare page hash results for recorded sampled page, Chuan Zheng, 2020/08/28
- [PATCH v6 12/12] migration/dirtyrate: Add trace_calls to make it easier to debug, Chuan Zheng, 2020/08/28
- [PATCH v6 11/12] migration/dirtyrate: Implement qmp_cal_dirty_rate()/qmp_get_dirty_rate() function, Chuan Zheng, 2020/08/28
- Re: [PATCH v6 00/12] *** A Method for evaluating dirty page rate ***, David Edmondson, 2020/08/31
- Re: [PATCH v6 00/12] *** A Method for evaluating dirty page rate ***,
Zheng Chuan <=