[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZowrFHHXNds36Nsb@slm.duckdns.org>
Date: Mon, 8 Jul 2024 08:08:20 -1000
From: Tejun Heo <tj@...nel.org>
To: Cheng Yu <serein.chengyu@...wei.com>
Cc: mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
vincent.guittot@...aro.org, dietmar.eggemann@....com,
rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
bristot@...hat.com, vschneid@...hat.com,
changhuaixin@...ux.alibaba.com, shanpeic@...ux.alibaba.com,
dtcccc@...ux.alibaba.com, vishalc@...ux.ibm.com,
linux-kernel@...r.kernel.org, zhangqiao22@...wei.com,
judy.chenhui@...wei.com, yusongping@...wei.com,
zhaowenhui8@...wei.com
Subject: Re: [PATCH v2] sched/fair: set burst to 0 when remove the
restriction on cfs bandwidth
Hello,
On Mon, Jul 08, 2024 at 08:00:53PM +0800, Cheng Yu wrote:
> From: Zhao Wenhui <zhaowenhui8@...wei.com>
>
> In the cpu subsystem of cgroup v1 and v2, we set the restriction on cfs
> bandwidth by setting the quota and burst value. Later, when we remove
> the restriction by setting the quota to the default value, the burst
> value should also be forced to the its default value of zero.
Explaining a bit why burst value should become zero can be helpful - ie.
what happens when quota is not set but burst is limited?
...
> @@ -10840,6 +10840,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;
This happening would be a bug, right? Would it make more sense to use
WARN_ON_ONCE()?
Thanks.
--
tejun
Powered by blists - more mailing lists