From: Yun Hsiang <hsiang023167@gmail.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: peterz@infradead.org, linux-kernel@vger.kernel.org,
qais.yousef@arm.com, patrick.bellasi@matbug.net
Subject: Re: [PATCH v2 1/1] sched/uclamp: add SCHED_FLAG_UTIL_CLAMP_RESET flag to reset uclamp
Date: Wed, 14 Oct 2020 23:00:34 +0800 [thread overview]
Message-ID: <20201014150034.GA502296@ubuntu> (raw)
In-Reply-To: <ae86aa70-2787-fe35-7ea6-2d1c4f4d9301@arm.com>
On Tue, Oct 13, 2020 at 10:25:48PM +0200, Dietmar Eggemann wrote:
> Hi Yun,
>
> On 12/10/2020 18:31, Yun Hsiang wrote:
> > If the user wants to stop controlling uclamp and let the task inherit
> > the value from the group, we need a method to reset.
> >
> > Add SCHED_FLAG_UTIL_CLAMP_RESET flag to allow the user to reset uclamp via
> > sched_setattr syscall.
>
> before we decide on how to implement the 'uclamp user_defined reset'
> feature, could we come back to your use case in
> https://lkml.kernel.org/r/20201002053812.GA176142@ubuntu ?
>
> Lets just consider uclamp min for now. We have:
>
> (1) system-wide:
>
> # cat /proc/sys/kernel/sched_util_clamp_min
>
> 1024
>
> (2) tg (hierarchy) with top-app's cpu.uclamp.min to ~200 (20% of 1024):
>
> # cat /sys/fs/cgroup/cpu/top-app/cpu.uclamp.min
> 20
>
> (3) and 2 cfs tasks A and B in top-app:
>
> # cat /sys/fs/cgroup/cpu/top-app/tasks
>
> pid_A
> pid_B
>
> Then you set A and B's uclamp min to 100. A and B are now user_defined.
> A and B's effective uclamp min value is 100.
>
> Since the task uclamp min values (3) are less than (1) and (2), their
> uclamp min value is not affected by (1) or (2).
>
> If A doesn't want to control itself anymore, it can set its uclamp min
> to e.g. 300. Now A's effective uclamp min value is ~200, i.e. controlled
> by (2), the one of B stays 100.
The tg uclamp value may also change. If top-app's cpu.uclamp.min change
to 50 (~500), then task A's effective uclamp min value is 300 not ~500.
We can set task A's uclamp to 1024, it will be restricted by the tg.
But when task A move to root group, it's effective uclamp min value
will be 1024 not 0. If a task is in root group and it doesn't want to
control it's uclamp, the effective uclamp min value of that task should be 0.
So I think reset functionality is needed.
>
> So the policy is:
>
> (a) If the user_defined task wants to control it's uclamp, use task
> uclamp value less than the tg (hierarchy) (and the system-wide)
> value.
>
> (b) If the user_defined task doesn't want to control it's uclamp
> anymore, use a uclamp value greater than or equal the tg (hierarchy)
> (and the system-wide) value.
>
> So where exactly is the use case which would require a 'uclamp
> user_defined reset' functionality?
next prev parent reply other threads:[~2020-10-14 15:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-12 16:31 [PATCH v2 1/1] sched/uclamp: add SCHED_FLAG_UTIL_CLAMP_RESET flag to reset uclamp Yun Hsiang
2020-10-13 8:21 ` Patrick Bellasi
2020-10-13 10:29 ` Qais Yousef
2020-10-13 11:46 ` Patrick Bellasi
2020-10-13 13:32 ` Qais Yousef
2020-10-13 16:52 ` Patrick Bellasi
2020-10-14 16:15 ` Yun Hsiang
2020-10-13 20:25 ` Dietmar Eggemann
2020-10-14 14:50 ` Patrick Bellasi
2020-10-15 11:53 ` Dietmar Eggemann
2020-10-14 15:00 ` Yun Hsiang [this message]
2020-10-15 11:56 ` Dietmar Eggemann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201014150034.GA502296@ubuntu \
--to=hsiang023167@gmail.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=patrick.bellasi@matbug.net \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).