lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 5 Oct 2020 18:15:00 +0100
From:   Qais Yousef <qais.yousef@....com>
To:     Patrick Bellasi <patrick.bellasi@...bug.net>
Cc:     Yun Hsiang <hsiang023167@...il.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        peterz@...radead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] sched/uclamp: release per-task uclamp control if
 user set to default value

On 10/05/20 18:58, Patrick Bellasi wrote:

[...]

> >> 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).
> 
> True, however it's also true that strictly speaking once a task has
> defined a per-task value, we will always aggregate/clamp that value wrt
> to TG and SystemWide value.
> 
> >> But the other tasks in the group will be affected by the group.
> 
> This is not clear to me.
> 
> All tasks in a group will be treated independently. All the tasks are
> subject to the same _individual_ aggregation/clamping policy.

I think the confusing bit is this check in uclamp_tg_restrict()

1085         uc_max = task_group(p)->uclamp[clamp_id];
1086         if (uc_req.value > uc_max.value || !uc_req.user_defined)
1087                 return uc_max;

If a task is !user_defined then it'll *inherit* the TG value. So you can end
up with 2 different behaviors based on that flag. I.e: if 2 tasks have their
util_min=0, but one is user_defined while the other isn't, the effective
uclamp value will look different for the 2 tasks.

IIUC, Yun wants to be able to reset this user_defined flag to re-enable this
inheritance behavior for a task. Which I agree with you, seems a sensible thing
to allow (via new sched_setattr() flag of course).

Thanks

--
Qais Yousef

Powered by blists - more mailing lists