Messages in this thread | | | Subject | Re: [PATCH] sched/uclamp: Avoid setting cpu.uclamp.min bigger than cpu.uclamp.max | From | Dietmar Eggemann <> | Date | Fri, 4 Jun 2021 18:22:42 +0200 |
| |
On 04/06/2021 18:08, Qais Yousef wrote: > On 06/03/21 10:24, Xuewen Yan wrote: >> +CC Qais > > Thanks for the CC :) > >> >> >> Hi Quentin >> >> On Wed, Jun 2, 2021 at 9:22 PM Quentin Perret <qperret@google.com> wrote: >>> >>> +CC Patrick and Tejun >>> >>> On Wednesday 02 Jun 2021 at 20:38:03 (+0800), Xuewen Yan wrote: >>>> From: Xuewen Yan <xuewen.yan@unisoc.com> >>>> >>>> When setting cpu.uclamp.min/max in cgroup, there is no validating >>>> like uclamp_validate() in __sched_setscheduler(). It may cause the >>>> cpu.uclamp.min is bigger than cpu.uclamp.max. >>> >>> ISTR this was intentional. We also allow child groups to ask for >>> whatever clamps they want, but that is always limited by the parent, and >>> reflected in the 'effective' values, as per the cgroup delegation model. > > As Quentin said. This intentional to comply with cgroup model. > > See Limits and Protections sections in Documentation/admin-guide/cgroup-v2.rst > > Specifically > > "all configuration combinations are valid" > > So user can set cpu.uclamp.min higher than cpu.uclamp.max. But when we apply > the setting, cpu.uclamp.min will be capped by cpu.uclamp.max. I can see you > found the cpu_util_update_eff() logic.
To support this:
Patrick had appropriate checks in his `[PATCH v10 12/16] sched/core: uclamp: Extend CPU's cgroup controller`.
https://lkml.kernel.org/r/20190621084217.8167-13-patrick.bellasi@arm.com
But is was discussed that cgroup v2 `resource distribution model` configurations (here protection/limit: uclamp_min/uclamp_max) should not be restricted.
Further down in this thread:
"... Limits always trump protection in effect of course but please don't limit what can be configured..."
| |