Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 7 Oct 2020 23:00:13 +0800
From:   Yun Hsiang <hsiang023167@gmail.com>
To:     Qais Yousef <qais.yousef@arm.com>
Cc:     Patrick Bellasi <patrick.bellasi@matbug.net>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        peterz@infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] sched/uclamp: release per-task uclamp control if
 user set to default value
Message-ID: <20201007150013.GA219885@ubuntu>
References: <20200928082643.133257-1-hsiang023167@gmail.com>
 <8272de8d-9868-d419-e2bb-d5e2c0614b63@arm.com>
 <20201002053812.GA176142@ubuntu>
 <57e6b3d3-22cd-0533-cfe7-e689c7983fcc@arm.com>
 <87o8lg7gpi.derkling@matbug.net>
 <20201005171500.eztpptd76fotkwa6@e107158-lin.cambridge.arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201005171500.eztpptd76fotkwa6@e107158-lin.cambridge.arm.com>
Precedence: bulk

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