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]
Message-ID: <20201002053812.GA176142@ubuntu>
Date:   Fri, 2 Oct 2020 13:38:12 +0800
From:   Yun Hsiang <hsiang023167@...il.com>
To:     Dietmar Eggemann <dietmar.eggemann@....com>
Cc:     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 Wed, Sep 30, 2020 at 03:12:51PM +0200, Dietmar Eggemann wrote:
Hi Dietmar,

> Hi Yun,
> 
> 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@...il.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.
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.
But the other tasks in the group will be affected by the group.

The policy might be
1) if the task wants to control it's uclamp, use task uclamp value
(but under group uclamp constraint)
2) if the task doesn't want to control it's uclamp, use group uclamp value.

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;
> >  	if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MIN) {
> >  		uclamp_se_set(&p->uclamp_req[UCLAMP_MIN],
> > -			      attr->sched_util_min, true);
> > +			      attr->sched_util_min, user_defined);
> >  	}
> >  
> > +	user_defined = attr->sched_util_max == 1024 ? false : true;
> >  	if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MAX) {
> >  		uclamp_se_set(&p->uclamp_req[UCLAMP_MAX],
> > -			      attr->sched_util_max, true);
> > +			      attr->sched_util_max, user_defined);
> >  	}
> >  }

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ