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
| ||
|
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