|
From: | Hyman |
Subject: | Re: [PATCH v9 3/3] cpus-common: implement dirty page limit on vCPU |
Date: | Mon, 6 Dec 2021 22:56:00 +0800 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 |
在 2021/12/6 16:28, Peter Xu 写道:
On Sat, Dec 04, 2021 at 08:00:19PM +0800, Hyman Huang wrote:在 2021/12/3 20:34, Markus Armbruster 写道:huangy81@chinatelecom.cn writes:From: Hyman Huang(黄勇) <huangy81@chinatelecom.cn> Implement dirtyrate calculation periodically basing on dirty-ring and throttle vCPU until it reachs the quota dirty page rate given by user. Introduce qmp commands "vcpu-dirty-limit", "query-vcpu-dirty-limit" to enable, disable, query dirty page limit for virtual CPU. Meanwhile, introduce corresponding hmp commands "vcpu_dirty_limit", "info vcpu_dirty_limit" so developers can play with them easier. Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>[...] I see you replaced the interface. Back to square one...diff --git a/qapi/migration.json b/qapi/migration.json index 3da8fdf..dc15b3f 100644 --- a/qapi/migration.json +++ b/qapi/migration.json @@ -1872,6 +1872,54 @@ 'current-rate': 'int64' } } ## +# @vcpu-dirty-limit: +# +# Set or cancel the upper limit of dirty page rate for a virtual CPU. +# +# Requires KVM with accelerator property "dirty-ring-size" set. +# A virtual CPU's dirty page rate is a measure of its memory load. +# To observe dirty page rates, use @calc-dirty-rate. +# +# @cpu-index: index of virtual CPU. +# +# @enable: true to enable, false to disable. +# +# @dirty-rate: upper limit of dirty page rate for virtual CPU. +# +# Since: 7.0 +# +# Example: +# {"execute": "vcpu-dirty-limit"} +# "arguments": { "cpu-index": 0, +# "enable": true, +# "dirty-rate": 200 } } +# +## +{ 'command': 'vcpu-dirty-limit', + 'data': { 'cpu-index': 'int', + 'enable': 'bool', + 'dirty-rate': 'uint64'} }When @enable is false, @dirty-rate makes no sense and is not used (I checked the code), but users have to specify it anyway. That's bad design. Better: drop @enable, make @dirty-rate optional, present means enable, absent means disable.Uh, if we drop @enable, enabling dirty limit should be like: vcpu-dirty-limit cpu-index=0 dirty-rate=1000 And disabling dirty limit like: vcpu-dirty-limit cpu-index=0 For disabling case, there is no hint of disabling in command "vcpu-dirty-limit". How about make @dirty-rate optional, when enable dirty limit, it should present, ignored otherwise?Sounds good, I think we can make both "enable" and "dirty-rate" optional. To turn it on we either use "enable=true,dirty-rate=XXX" or "dirty-rate=XXX" > To turn it off we use "enable=false".
Indeed, this make things more convenient.
That's question, how about adding an optional argument "global" and making "cpu-index", "enable", "dirty-rate" all optional in "vcpu-dirty-limit", keeping the "cpu-index" and "global" options mutually exclusive?>>+ +## +# @query-vcpu-dirty-limit: +# +# Returns information about the virtual CPU dirty limit status. +# +# @cpu-index: index of the virtual CPU to query, if not specified, all +# virtual CPUs will be queried. +# +# Since: 7.0 +# +# Example: +# {"execute": "query-vcpu-dirty-limit"} +# "arguments": { "cpu-index": 0 } } +# +## +{ 'command': 'query-vcpu-dirty-limit', + 'data': { '*cpu-index': 'int' }, + 'returns': [ 'DirtyLimitInfo' ] }Why would anyone ever want to specify @cpu-index? Output isn't that large even if you have a few hundred CPUs. Let's keep things simple and drop the parameter.Ok, this make things simple.I found that it'll be challenging for any human being to identify "whether he/she has turned throttle off for all vcpus".. I think that could be useful when we finally decided to cancel current migration.
{ 'command': 'vcpu-dirty-limit', 'data': { '*cpu-index': 'int', '*global': 'bool' '*enable': 'bool', '*dirty-rate': 'uint64'} } In the case of enabling all vcpu throttle:Either use "global=true,enable=true,dirty-rate=XXX" or "global=true,dirty-rate=XXX"
In the case of disabling all vcpu throttle: use "global=true,enable=false,dirty-rate=XXX"In other case, we pass the same option just like what we did for specified vcpu throttle before.
I thought about adding a "global=on/off" flag, but instead can we just return the vcpu info for the ones that enabled the per-vcpu throttling? For anyone who wants to read all vcpu dirty information he/she can use calc-dirty-rate.
Ok, I'll pick up this advice next version.
Thanks,
[Prev in Thread] | Current Thread | [Next in Thread] |