From: Phil Auld <pauld@redhat.com>
To: 刘嵩 <liusong@linux.alibaba.com>
Cc: tj@kernel.org, lizefan.x@bytedance.com, hannes@cmpxchg.org,
"Michal Koutný" <mkoutny@suse.com>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] sched, cgroup: cgroup1 can also take the non-RUNTIME_INF min
Date: Tue, 10 Sep 2024 08:12:03 -0400 [thread overview]
Message-ID: <20240910121203.GD318990@pauld.westford.csb> (raw)
In-Reply-To: <0339F628-43F2-40D1-B199-5E641C238CAC@linux.alibaba.com>
On Tue, Sep 10, 2024 at 07:13:32PM +0800 刘嵩 wrote:
>
>
> > 2024年9月10日 18:49,Phil Auld <pauld@redhat.com> 写道:
> >
> >
> > Hi,
> >
> > On Tue, Sep 10, 2024 at 03:48:32PM +0800 Liu Song wrote:
> >> For the handling logic of child_quota, there is no need to distinguish
> >> between cgroup1 and cgroup2, so unify the handling logic here.
> >>
> >> Signed-off-by: Liu Song <liusong@linux.alibaba.com>
> >> ---
> >> kernel/sched/core.c | 21 +++++----------------
> >> 1 file changed, 5 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> >> index e752146e59a4..8418c67faa69 100644
> >> --- a/kernel/sched/core.c
> >> +++ b/kernel/sched/core.c
> >> @@ -9501,23 +9501,12 @@ static int tg_cfs_schedulable_down(struct task_group *tg, void *data)
> >> parent_quota = parent_b->hierarchical_quota;
> >>
> >> /*
> >> - * Ensure max(child_quota) <= parent_quota. On cgroup2,
> >> - * always take the non-RUNTIME_INF min. On cgroup1, only
> >> - * inherit when no limit is set. In both cases this is used
> >> - * by the scheduler to determine if a given CFS task has a
> >> - * bandwidth constraint at some higher level.
> >
> > This comment is here for a reason. Please don't remove it.
>
> Hi
>
> I don’t see why cgroup1 needs to impose this restriction while cgroup2
> can directly take the non-RUNTIME_INF minimum value. What is the
> necessity of this?
>
That's how cgroupv1 bandwidth control is defined. See
Documentation/scheduler/sched-bcw.rst.
> It seems more reasonable to unify the handling logic. Even if the child
> group quota exceeds the parent group quota, it would not actually take
> effect.
>
It's not about it taking effect or not. You are not supposed to be
allowed to configure a child quota > parent quota. It's supposed to
be an error.
Also, my comment about the comment specifically is that last sentence, which
explains that other parts of the scheduler rely on this being set correctly,
needs to remain. But since I don't think this change is right, that should
not be an issue.
Cheers,
Phil
> However, if the parent group quota is reset to a larger value, then the
> child group quota would have actual significance. Therefore, the handling
> logic should be consistent between cgroup1 and cgroup2.
>
> Thanks
>
>
> >
> >> + * Ensure max(child_quota) <= parent_quota.
> >> */
> >> - if (cgroup_subsys_on_dfl(cpu_cgrp_subsys)) {
> >> - if (quota == RUNTIME_INF)
> >> - quota = parent_quota;
> >> - else if (parent_quota != RUNTIME_INF)
> >> - quota = min(quota, parent_quota);
> >> - } else {
> >> - if (quota == RUNTIME_INF)
> >> - quota = parent_quota;
> >> - else if (parent_quota != RUNTIME_INF && quota > parent_quota)
> >> - return -EINVAL;
> >> - }
> >> + if (quota == RUNTIME_INF)
> >> + quota = parent_quota;
> >> + else if (parent_quota != RUNTIME_INF)
> >> + quota = min(quota, parent_quota);
> >> }
> >> cfs_b->hierarchical_quota = quota;
> >>
> >
> > I don't think there is a need to optimize this slow path
> > to allow setting invalid values which have to be handled in
> > fast paths. And this will change expected behavior.
> >
> > So NAK.
> >
> > Cheers,
> > Phil
> >
> > --
>
--
next prev parent reply other threads:[~2024-09-10 12:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-10 7:48 [RFC PATCH] sched, cgroup: cgroup1 can also take the non-RUNTIME_INF min Liu Song
2024-09-10 9:35 ` Michal Koutný
2024-09-10 10:05 ` 刘嵩
2024-09-10 10:49 ` Phil Auld
2024-09-10 11:13 ` 刘嵩
2024-09-10 12:12 ` Phil Auld [this message]
2024-09-10 19:32 ` Tejun Heo
2024-09-11 1:53 ` 刘嵩
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240910121203.GD318990@pauld.westford.csb \
--to=pauld@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liusong@linux.alibaba.com \
--cc=lizefan.x@bytedance.com \
--cc=mkoutny@suse.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox