sched/fair: set burst to zero when cfs bandwidth is cancelled
Cheng Yu (1): sched/fair: set burst to zero when set max to cpu.max
Zhao Wenhui (1): sched/fair: limit burst to zero when cfs bandwidth is toggled off
kernel/sched/core.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
From: Zhao Wenhui zhaowenhui8@huawei.com
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9PR8C CVE: NA
--------------------------------
sched/fair: limit burst to zero when cfs bandwidth is toggled off
When the quota value in CFS bandwidth is set to -1, that imples the cfs bandwidth is toggled off. So the burst feature is supposed to be disable as well.
Currently, when quota is -1, burst will not be check, so that it can be set to almost arbitery value. Examples: mkdir /sys/fs/cgroup/cpu/test echo -1 > /sys/fs/cgroup/cpu/test/cpu.cfs_quota_us echo 10000000000000000 > /sys/fs/cgroup/cpu/test/cpu.cfs_burst_us
Moreover, after the burst modified by this way, quota can't be set to any value: echo 100000 > cpu.cfs_quota_us -bash: echo: write error: Invalid argument
This patch can ensure the burst value being zero and unalterable, when quota is set to -1.
Fixes: f4183717b370 ("sched/fair: Introduce the burstable CFS controller") Signed-off-by: Zhao Wenhui zhaowenhui8@huawei.com Signed-off-by: Cheng Yu serein.chengyu@huawei.com --- kernel/sched/core.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 9e7a99947de6..5441afe18953 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -11051,6 +11051,12 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, u64 period, u64 quota, burst + quota > max_cfs_runtime)) return -EINVAL;
+ /* + * Ensure burst equals to zero when quota is -1. + */ + if (quota == RUNTIME_INF && burst) + return -EINVAL; + /* * Prevent race between setting of cfs_rq->runtime_enabled and * unthrottle_offline_cfs_rqs(). @@ -11110,8 +11116,10 @@ static int tg_set_cfs_quota(struct task_group *tg, long cfs_quota_us)
period = ktime_to_ns(tg->cfs_bandwidth.period); burst = tg->cfs_bandwidth.burst; - if (cfs_quota_us < 0) + if (cfs_quota_us < 0) { quota = RUNTIME_INF; + burst = 0; + } else if ((u64)cfs_quota_us <= U64_MAX / NSEC_PER_USEC) quota = (u64)cfs_quota_us * NSEC_PER_USEC; else
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9PR8C CVE: NA
--------------------------------
In the cgroup v2 cpu subsystem, assuming we have a cgroup named test, we set cpu.max and cpu.max.burst: # echo 1000000 > /sys/fs/cgroup/test/cpu.max # echo 1000000 > /sys/fs/cgroup/test/cpu.max.burst
Next we remove the restriction on cfs bandwidth: # echo max > /sys/fs/cgroup/test/cpu.max # cat /sys/fs/cgroup/test/cpu.max max 100000 # cat /sys/fs/cgroup/test/cpu.max.burst 1000000
Now we expect that the value of burst should be 0. When the burst is 0, it means that the restriction on burst is cancelled.
Fixes: f4183717b370 ("sched/fair: Introduce the burstable CFS controller") Signed-off-by: Cheng Yu serein.chengyu@huawei.com --- kernel/sched/core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 5441afe18953..f5b929ef9652 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -12060,8 +12060,11 @@ static ssize_t cpu_max_write(struct kernfs_open_file *of, int ret;
ret = cpu_period_quota_parse(buf, &period, "a); - if (!ret) + if (!ret) { + if (quota == RUNTIME_INF) + burst = 0; ret = tg_set_cfs_bandwidth(tg, period, quota, burst); + } return ret ?: nbytes; } #endif
反馈: 您发送到kernel@openeuler.org的补丁/补丁集,已成功转换为PR! PR链接地址: https://gitee.com/openeuler/kernel/pulls/7474 邮件列表地址:https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/M...
FeedBack: The patch(es) which you have sent to kernel@openeuler.org mailing list has been converted to a pull request successfully! Pull request link: https://gitee.com/openeuler/kernel/pulls/7474 Mailing list address: https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/M...