Il giorno 24 ago 2021, alle ore 12:56, Michal Koutný [off-list ref] ha scritto:
Hello.
The default weight for proportional IO control associated with a cgroup
is 100 [1]. The minimum allowed weight is 1 [2] and the maximum weight
1000 [3]. This is a bit inconsistent with general cgroup weight
semantic where def/min == max/def (i.e. symmetric adjustments to both
sides) [4].
1) Is there a reason why the maximum allowed weight is (only) 1000?
(E.g. it won't be possible to ensure 10^4 ratio of proportional
control but 10^3 is achievable.)
2) Is the default value 100 special or absolute in a sense? (I suspect
it is, the unchangeable weight of root cgroup members. Therefore two
siblings with equal ratios 10:100 and 100:1000 would behave same only
when there's no interfering IO from the root.)
Hi,
BFQ inherited these constants when we forked it from CFQ. I'm ok with
increasing max weight to 10000. I only wonder whether this would
break some configuration, as the currently maximum weight would not be
the maximum weight any longer.
Thanks,
Paolo
Thanks,
Michal
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/block/bfq-cgroup.c?h=v5.14-rc7#n513
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/block/bfq-iosched.h?h=v5.14-rc7#n18
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/block/bfq-iosched.h?h=v5.14-rc7#n19
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/cgroup-v2.rst?h=v5.14-rc7#n602
On Tue, Aug 24, 2021 at 02:51:47PM +0200, Paolo Valente [off-list ref] wrote:
BFQ inherited these constants when we forked it from CFQ. I'm ok with
increasing max weight to 10000. I only wonder whether this would
break some configuration, as the currently maximum weight would not be
the maximum weight any longer.
Thanks for the reply. Let me form the idea as a patch (and commit
message) and discuss based on that if needed (+ccrosspost into cgroups
ML).
-- >8 --
From: Michal Koutný <mkoutny@suse.com>
Subject: [PATCH] block, bfq: Accept symmetric weight adjustments
The allowed range for BFQ weights is currently 1..1000 with 100 being
the default. There is no apparent reason to not accept weight
adjustments of same ratio on both sides of the default. This change
makes the attribute domain consistent with other cgroup (v2) knobs with
the weight semantics.
This extension of the range does not restrict existing configurations
(quite the opposite). This may affect setups where weights >1000 were
attempted to be set but failed with the default 100. Such cgroups would
attain their intended weight now. This is a changed behavior but it
rectifies the situation (similar intention to the commit 69d7fde5909b
("blkcg: use CGROUP_WEIGHT_* scale for io.weight on the unified
hierarchy") for CFQ formerly (and v2 only)).
Additionally, the changed range does not imply all IO workloads can be
really controlled to achieve the widest possible ratio 1:10^4.
Signed-off-by: Michal Koutný <mkoutny@suse.com>
---
Documentation/admin-guide/cgroup-v1/blkio-controller.rst | 2 +-
Documentation/block/bfq-iosched.rst | 2 +-
block/bfq-iosched.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst
index 16253eda192e..48559541c9d8 100644
--- a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst
+++ b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst
@@ -102,7 +102,7 @@ Proportional weight policy files
on all the devices until and unless overridden by per device rule
(see `blkio.bfq.weight_device` below).
- Currently allowed range of weights is from 1 to 1000. For more details,
+ Currently allowed range of weights is from 1 to 10000. For more details,
see Documentation/block/bfq-iosched.rst.
blkio.bfq.weight_devicediff --git a/Documentation/block/bfq-iosched.rst b/Documentation/block/bfq-iosched.rst
index df3a8a47f58c..88b5251734ce 100644
--- a/Documentation/block/bfq-iosched.rst
+++ b/Documentation/block/bfq-iosched.rst
@@ -560,7 +560,7 @@ For each group, the following parameters can be set:
weight
This specifies the default weight for the cgroup inside its parent.
- Available values: 1..1000 (default: 100).
+ Available values: 1..10000 (default: 100).
For cgroup v1, it is set by writing the value to `blkio.bfq.weight`.
diff --git a/block/bfq-iosched.h b/block/bfq-iosched.h
index 99c2a3cb081e..786b7f926dd2 100644
--- a/block/bfq-iosched.h
+++ b/block/bfq-iosched.h
@@ -16,7 +16,7 @@
#define BFQ_CL_IDLE_TIMEOUT (HZ/5)
#define BFQ_MIN_WEIGHT 1
-#define BFQ_MAX_WEIGHT 1000
+#define BFQ_MAX_WEIGHT 10000
#define BFQ_WEIGHT_CONVERSION_COEFF 10
#define BFQ_DEFAULT_QUEUE_IOPRIO 4
--
2.32.0
On Thu, Aug 26, 2021 at 03:12:12PM +0200, Michal Koutný wrote:
On Tue, Aug 24, 2021 at 02:51:47PM +0200, Paolo Valente [off-list ref] wrote:
quoted
BFQ inherited these constants when we forked it from CFQ. I'm ok with
increasing max weight to 10000. I only wonder whether this would
break some configuration, as the currently maximum weight would not be
the maximum weight any longer.
Thanks for the reply. Let me form the idea as a patch (and commit
message) and discuss based on that if needed (+ccrosspost into cgroups
ML).
-- >8 --
From: Michal Koutný <mkoutny@suse.com>
Subject: [PATCH] block, bfq: Accept symmetric weight adjustments
The allowed range for BFQ weights is currently 1..1000 with 100 being
the default. There is no apparent reason to not accept weight
adjustments of same ratio on both sides of the default. This change
makes the attribute domain consistent with other cgroup (v2) knobs with
the weight semantics.
This extension of the range does not restrict existing configurations
(quite the opposite). This may affect setups where weights >1000 were
attempted to be set but failed with the default 100. Such cgroups would
attain their intended weight now. This is a changed behavior but it
rectifies the situation (similar intention to the commit 69d7fde5909b
("blkcg: use CGROUP_WEIGHT_* scale for io.weight on the unified
hierarchy") for CFQ formerly (and v2 only)).
Additionally, the changed range does not imply all IO workloads can be
really controlled to achieve the widest possible ratio 1:10^4.
Signed-off-by: Michal Koutný <mkoutny@suse.com>
Looks fine to me.
Acked-by: Tejun Heo <tj@kernel.org>
Thanks.
--
tejun
Il giorno 26 ago 2021, alle ore 19:25, Tejun Heo [off-list ref] ha scritto:
On Thu, Aug 26, 2021 at 03:12:12PM +0200, Michal Koutný wrote:
quoted
On Tue, Aug 24, 2021 at 02:51:47PM +0200, Paolo Valente [off-list ref] wrote:
quoted
BFQ inherited these constants when we forked it from CFQ. I'm ok with
increasing max weight to 10000. I only wonder whether this would
break some configuration, as the currently maximum weight would not be
the maximum weight any longer.
Thanks for the reply. Let me form the idea as a patch (and commit
message) and discuss based on that if needed (+ccrosspost into cgroups
ML).
-- >8 --
From: Michal Koutný <mkoutny@suse.com>
Subject: [PATCH] block, bfq: Accept symmetric weight adjustments
The allowed range for BFQ weights is currently 1..1000 with 100 being
the default. There is no apparent reason to not accept weight
adjustments of same ratio on both sides of the default. This change
makes the attribute domain consistent with other cgroup (v2) knobs with
the weight semantics.
This extension of the range does not restrict existing configurations
(quite the opposite). This may affect setups where weights >1000 were
attempted to be set but failed with the default 100. Such cgroups would
attain their intended weight now. This is a changed behavior but it
rectifies the situation (similar intention to the commit 69d7fde5909b
("blkcg: use CGROUP_WEIGHT_* scale for io.weight on the unified
hierarchy") for CFQ formerly (and v2 only)).
Additionally, the changed range does not imply all IO workloads can be
really controlled to achieve the widest possible ratio 1:10^4.
Signed-off-by: Michal Koutný <mkoutny@suse.com>
Looks fine to me.
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Paolo Valente <redacted>
Thanks for this improvement,
Paolo
Thanks.
--
tejun