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

[David Edmondson]

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.
-- 
Modern people tend to dance.