On Mon, Oct 05, 2020 at 06:15:00PM +0100, Qais Yousef wrote: > 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). >
Yes, this is what I want. As Dietmar and Pavan said, use 0 and 1024 to reset user_defined is problematic. I'll send a V2 patch that use SCHED_FLAG_UTIL_CLAMP_RESET to reset the user_defined bit. Thank for the suggestion! > > Thanks > > -- > Qais Yousef > Thanks, Yun
