Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Qais Yousef <firstname.lastname@example.org>
To: Valentin Schneider <email@example.com>
Cc: Ingo Molnar <firstname.lastname@example.org>,
Peter Zijlstra <email@example.com>,
Doug Anderson <firstname.lastname@example.org>,
Jonathan Corbet <email@example.com>,
Juri Lelli <firstname.lastname@example.org>,
Vincent Guittot <email@example.com>,
Dietmar Eggemann <firstname.lastname@example.org>,
Steven Rostedt <email@example.com>,
Ben Segall <firstname.lastname@example.org>, Mel Gorman <email@example.com>,
Luis Chamberlain <firstname.lastname@example.org>,
Kees Cook <email@example.com>,
Iurii Zaikin <firstname.lastname@example.org>,
Quentin Perret <email@example.com>,
Patrick Bellasi <firstname.lastname@example.org>,
Pavan Kondeti <email@example.com>,
Subject: Re: [PATCH v6 1/2] sched/uclamp: Add a new sysctl to control RT default boost value
Date: Tue, 7 Jul 2020 13:58:27 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 07/07/20 12:39, Valentin Schneider wrote:
> 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
cmdline is not userfriendly. A person who installs a new distro on their laptop
can easily modify a sysctl knob to squeeze maximum battery life, but not play
with grub and bootloader to add a cmdline option.
> 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.
This was addressed before. This is not flexible and having a daemon that
monitors RT tasks as they come and go is terrible IMO.
If you're suggesting to hardcode it to 0, then this is not what we're trying to
I don't think we've hit a wall where things look really ugly to not continue
pursue this flexible and more robust solution.
next prev parent reply other threads:[~2020-07-07 12:58 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 " 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
2020-07-07 12:58 ` Qais Yousef [this message]
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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH v6 1/2] sched/uclamp: Add a new sysctl to control RT default boost value' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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).