Re: [PATCH 1/1] sched/uclamp: release per-task uclamp control if user set to default value

[Dietmar Eggemann <dietmar.eggemann@arm.com>]

+ Patrick Bellasi <patrick.bellasi@matbug.net>
+ Qais Yousef <qais.yousef@arm.com>

On 02.10.20 07:38, Yun Hsiang wrote:
> On Wed, Sep 30, 2020 at 03:12:51PM +0200, Dietmar Eggemann wrote:

[...]

>> On 28/09/2020 10:26, Yun Hsiang wrote:
>>> If the user wants to release the util clamp and let cgroup to control it,
>>> we need a method to reset.
>>>
>>> So if the user set the task uclamp to the default value (0 for UCLAMP_MIN
>>> and 1024 for UCLAMP_MAX), reset the user_defined flag to release control.
>>>
>>> Signed-off-by: Yun Hsiang <hsiang023167@gmail.com>
>>
>> could you explain with a little bit more detail why you would need this
>> feature?
>>
>> Currently we assume that once the per-task uclamp (user-defined) values
>> are set, you could only change the effective uclamp values of this task
>> by (1) moving it into another taskgroup or (2) changing the system
>> default uclamp values.
>>
> 
> Assume a module that controls group (such as top-app in android) uclamp and
> task A in the group.
> Once task A set uclamp, it will not be affected by the group setting.

This depends on the uclamp values of A and /TG (the task group).

Both uclamp values are max aggregated (max aggregation between
system-wide, taskgroup and task values for UCLAMP_MIN and UCLAMP_MAX).

(1) system-wide: /proc/sys/kernel/sched_util_clamp_[min,max]

(2) taskgroup (hierarchy): /sys/fs/cgroup/cpu/TG/cpu.uclamp.[min,max]

(3) task A:

Example: [uclamp_min, uclamp_max]

(1)  [1024, 1024]

(2)  [25.00 (256), 75.00 (768)]

(3a) [128, 512] : both values are not affected by /TG

(3b) [384, 896] : both values are affected by /TG


> If task A doesn't want to control itself anymore,
> it can not go back to the initial state to let the module(group) control.

In case A changes its values e.g. from 3a to 3b it will go back to be
controlled by /TG again (like it was when it had no user defined values).

> But the other tasks in the group will be affected by the group.

Yes, in case they have no user defined values or have values greater
than the one of /TG.

> The policy might be
> 1) if the task wants to control it's uclamp, use task uclamp value
> (but under group uclamp constraint)

That would be example 3a.

> 2) if the task doesn't want to control it's uclamp, use group uclamp value.

That would be example 3b.

> If the policy is proper, we need a reset method for per-task uclamp.
> 
>>> ---
>>>  kernel/sched/core.c | 7 +++++--
>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>>> index 9a2fbf98fd6f..fa63d70d783a 100644
>>> --- a/kernel/sched/core.c
>>> +++ b/kernel/sched/core.c
>>> @@ -1187,6 +1187,7 @@ static void __setscheduler_uclamp(struct task_struct *p,
>>>  				  const struct sched_attr *attr)
>>>  {
>>>  	enum uclamp_id clamp_id;
>>> +	bool user_defined;
>>>  
>>>  	/*
>>>  	 * On scheduling class change, reset to default clamps for tasks
>>> @@ -1210,14 +1211,16 @@ static void __setscheduler_uclamp(struct task_struct *p,
>>>  	if (likely(!(attr->sched_flags & SCHED_FLAG_UTIL_CLAMP)))
>>>  		return;
>>>  
>>> +	user_defined = attr->sched_util_min == 0 ? false : true;

In case we would need a way to reset user defined values, using 0 and
1024 for this is problematic because both are valid uclamp values.
But I'm pretty sure you can avoid this by using the max aggregation
between A and /TG to turn task uclamp values on or off.
This is obviously also true when A moves from /TG into another taskgroup
with appropriate uclamp values.

[...]