lkml.org 
[lkml]   [2021]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] sched/uclamp: Avoid setting cpu.uclamp.min bigger than cpu.uclamp.max
From
Date
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..."

\
 
 \ /
  Last update: 2021-06-04 18:23    [W:0.113 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site