Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: Qais Yousef <qais.yousef@arm.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Doug Anderson <dianders@chromium.org>,
Jonathan Corbet <corbet@lwn.net>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Luis Chamberlain <mcgrof@kernel.org>,
Kees Cook <keescook@chromium.org>,
Iurii Zaikin <yzaikin@google.com>,
Quentin Perret <qperret@google.com>,
Patrick Bellasi <patrick.bellasi@matbug.net>,
Pavan Kondeti <pkondeti@codeaurora.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v6 1/2] sched/uclamp: Add a new sysctl to control RT default boost value
Date: Tue, 07 Jul 2020 12:39:48 +0100 [thread overview]
Message-ID: <jhj1rln8sfv.mognet@arm.com> (raw)
In-Reply-To: <20200706142839.26629-2-qais.yousef@arm.com>
On 06/07/20 15:28, Qais Yousef wrote:
> RT tasks by default run at the highest capacity/performance level. When
> uclamp is selected this default behavior is retained by enforcing the
> requested uclamp.min (p->uclamp_req[UCLAMP_MIN]) of the RT tasks to be
> uclamp_none(UCLAMP_MAX), which is SCHED_CAPACITY_SCALE; the maximum
> value.
>
> This is also referred to as 'the default boost value of RT tasks'.
>
> See commit 1a00d999971c ("sched/uclamp: Set default clamps for RT tasks").
>
> On battery powered devices, it is desired to control this default
> (currently hardcoded) behavior at runtime to reduce energy consumed by
> RT tasks.
>
> For example, a mobile device manufacturer where big.LITTLE architecture
> is dominant, the performance of the little cores varies across SoCs, and
> on high end ones the big cores could be too power hungry.
>
> Given the diversity of SoCs, the new knob allows manufactures to tune
> the best performance/power for RT tasks for the particular hardware they
> run on.
>
> They could opt to further tune the value when the user selects
> a different power saving mode or when the device is actively charging.
>
> The runtime aspect of it further helps in creating a single kernel image
> that can be run on multiple devices that require different tuning.
>
> Keep in mind that a lot of RT tasks in the system are created by the
> kernel. On Android for instance I can see over 50 RT tasks, only
> a handful of which created by the Android framework.
>
> To control the default behavior globally by system admins and device
> integrator, introduce the new sysctl_sched_uclamp_util_min_rt_default
> to change the default boost value of the RT tasks.
>
> I anticipate this to be mostly in the form of modifying the init script
> of a particular device.
>
Sorry for going at this again, but I feel like I can squeeze more juice out
of this.
This being mainly tweaked in init scripts makes me question why we should
harden this for runtime tweaking. Yes, there's the whole single image
thing, but there's other ways to have different init-time values on a
single image (e.g. cmdline, although that one is usually a bit
controversial).
For instance, Android could set the min to 0 and then go about its life
tweaking the clamp of individual / all RT tasks at runtime, using the
existing uclamp API.
next prev parent reply other threads:[~2020-07-07 11:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-06 14:28 [PATCH v6 0/2] sched/uclamp: new sysctl for default RT boost value Qais Yousef
2020-07-06 14:28 ` [PATCH v6 1/2] sched/uclamp: Add a new sysctl to control RT default " Qais Yousef
2020-07-06 15:49 ` Valentin Schneider
2020-07-07 9:34 ` Qais Yousef
2020-07-07 11:30 ` Valentin Schneider
2020-07-07 12:36 ` Qais Yousef
2020-07-08 11:05 ` Valentin Schneider
2020-07-08 13:08 ` Qais Yousef
2020-07-08 21:45 ` Valentin Schneider
2020-07-07 11:39 ` Valentin Schneider [this message]
2020-07-07 12:58 ` Qais Yousef
2020-07-13 11:21 ` Peter Zijlstra
2020-07-13 11:36 ` peterz
2020-07-13 12:12 ` Qais Yousef
2020-07-13 13:35 ` Peter Zijlstra
2020-07-13 14:27 ` Qais Yousef
2020-07-13 16:54 ` Peter Zijlstra
2020-07-13 18:09 ` Qais Yousef
2020-07-06 14:28 ` [PATCH v6 2/2] Documentation/sysctl: Document uclamp sysctl knobs Qais Yousef
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=jhj1rln8sfv.mognet@arm.com \
--to=valentin.schneider@arm.com \
--cc=bsegall@google.com \
--cc=corbet@lwn.net \
--cc=dianders@chromium.org \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=patrick.bellasi@matbug.net \
--cc=peterz@infradead.org \
--cc=pkondeti@codeaurora.org \
--cc=qais.yousef@arm.com \
--cc=qperret@google.com \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=yzaikin@google.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).