Messages in this thread | | | Subject | Re: [PATCH 1/1] sched/uclamp: release per-task uclamp control if user set to default value | From | Dietmar Eggemann <> | Date | Mon, 5 Oct 2020 14:38:18 +0200 |
| |
+ 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.
[...]
| |