From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Patrick Bellasi <patrick.bellasi@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
linux-api@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>, Tejun Heo <tj@kernel.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Paul Turner <pjt@google.com>,
Quentin Perret <quentin.perret@arm.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Juri Lelli <juri.lelli@redhat.com>, Todd Kjos <tkjos@google.com>,
Joel Fernandes <joelaf@google.com>,
Steve Muckle <smuckle@google.com>,
Suren Baghdasaryan <surenb@google.com>
Subject: Re: [PATCH v6 08/16] sched/cpufreq: uclamp: Add utilization clamping for FAIR tasks
Date: Tue, 22 Jan 2019 11:37:42 +0100 [thread overview]
Message-ID: <3006911.57lVBuUGX3@aspire.rjw.lan> (raw)
In-Reply-To: <20190115101513.2822-9-patrick.bellasi@arm.com>
On Tuesday, January 15, 2019 11:15:05 AM CET Patrick Bellasi wrote:
> Each time a frequency update is required via schedutil, a frequency is
> selected to (possibly) satisfy the utilization reported by each
> scheduling class. However, when utilization clamping is in use, the
> frequency selection should consider userspace utilization clamping
> hints. This will allow, for example, to:
>
> - boost tasks which are directly affecting the user experience
> by running them at least at a minimum "requested" frequency
>
> - cap low priority tasks not directly affecting the user experience
> by running them only up to a maximum "allowed" frequency
>
> These constraints are meant to support a per-task based tuning of the
> frequency selection thus supporting a fine grained definition of
> performance boosting vs energy saving strategies in kernel space.
>
> Add support to clamp the utilization and IOWait boost of RUNNABLE FAIR
> tasks within the boundaries defined by their aggregated utilization
> clamp constraints.
> Based on the max(min_util, max_util) of each task, max-aggregated the
> CPU clamp value in a way to give the boosted tasks the performance they
> need when they happen to be co-scheduled with other capped tasks.
>
> Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> ---
> Changes in v6:
> Message-ID: <20181107113849.GC14309@e110439-lin>
> - sanity check util_max >= util_min
> Others:
> - wholesale s/group/bucket/
> - wholesale s/_{get,put}/_{inc,dec}/ to match refcount APIs
> ---
> kernel/sched/cpufreq_schedutil.c | 27 ++++++++++++++++++++++++---
> kernel/sched/sched.h | 23 +++++++++++++++++++++++
> 2 files changed, 47 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> index 033ec7c45f13..520ee2b785e7 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -218,8 +218,15 @@ unsigned long schedutil_freq_util(int cpu, unsigned long util_cfs,
> * CFS tasks and we use the same metric to track the effective
> * utilization (PELT windows are synchronized) we can directly add them
> * to obtain the CPU's actual utilization.
> + *
> + * CFS utilization can be boosted or capped, depending on utilization
> + * clamp constraints requested by currently RUNNABLE tasks.
> + * When there are no CFS RUNNABLE tasks, clamps are released and
> + * frequency will be gracefully reduced with the utilization decay.
> */
> - util = util_cfs;
> + util = (type == ENERGY_UTIL)
> + ? util_cfs
> + : uclamp_util(rq, util_cfs);
> util += cpu_util_rt(rq);
>
> dl_util = cpu_util_dl(rq);
> @@ -327,6 +334,7 @@ static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, u64 time,
> unsigned int flags)
> {
> bool set_iowait_boost = flags & SCHED_CPUFREQ_IOWAIT;
> + unsigned int max_boost;
>
> /* Reset boost if the CPU appears to have been idle enough */
> if (sg_cpu->iowait_boost &&
> @@ -342,11 +350,24 @@ static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, u64 time,
> return;
> sg_cpu->iowait_boost_pending = true;
>
> + /*
> + * Boost FAIR tasks only up to the CPU clamped utilization.
> + *
> + * Since DL tasks have a much more advanced bandwidth control, it's
> + * safe to assume that IO boost does not apply to those tasks.
> + * Instead, since RT tasks are not utilization clamped, we don't want
> + * to apply clamping on IO boost while there is blocked RT
> + * utilization.
> + */
> + max_boost = sg_cpu->iowait_boost_max;
> + if (!cpu_util_rt(cpu_rq(sg_cpu->cpu)))
> + max_boost = uclamp_util(cpu_rq(sg_cpu->cpu), max_boost);
> +
> /* Double the boost at each request */
> if (sg_cpu->iowait_boost) {
> sg_cpu->iowait_boost <<= 1;
> - if (sg_cpu->iowait_boost > sg_cpu->iowait_boost_max)
> - sg_cpu->iowait_boost = sg_cpu->iowait_boost_max;
> + if (sg_cpu->iowait_boost > max_boost)
> + sg_cpu->iowait_boost = max_boost;
> return;
> }
>
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index b7f3ee8ba164..95d62a2a0b44 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -2267,6 +2267,29 @@ static inline unsigned int uclamp_none(int clamp_id)
> return SCHED_CAPACITY_SCALE;
> }
>
> +#ifdef CONFIG_UCLAMP_TASK
> +static inline unsigned int uclamp_util(struct rq *rq, unsigned int util)
> +{
> + unsigned int min_util = READ_ONCE(rq->uclamp[UCLAMP_MIN].value);
> + unsigned int max_util = READ_ONCE(rq->uclamp[UCLAMP_MAX].value);
> +
> + /*
> + * Since CPU's {min,max}_util clamps are MAX aggregated considering
> + * RUNNABLE tasks with _different_ clamps, we can end up with an
> + * invertion, which we can fix at usage time.
> + */
> + if (unlikely(min_util >= max_util))
> + return min_util;
> +
> + return clamp(util, min_util, max_util);
> +}
> +#else /* CONFIG_UCLAMP_TASK */
> +static inline unsigned int uclamp_util(struct rq *rq, unsigned int util)
> +{
> + return util;
> +}
> +#endif /* CONFIG_UCLAMP_TASK */
> +
> #ifdef arch_scale_freq_capacity
> # ifndef arch_scale_freq_invariant
> # define arch_scale_freq_invariant() true
>
IMO it would be better to combine this patch with the next one.
At least some things in it I was about to ask about would go away
then. :-)
Besides, I don't really see a reason for the split here.
next prev parent reply other threads:[~2019-01-22 10:38 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-15 10:14 [PATCH v6 00/16] Add utilization clamping support Patrick Bellasi
2019-01-15 10:14 ` [PATCH v6 01/16] sched/core: Allow sched_setattr() to use the current policy Patrick Bellasi
2019-01-25 13:56 ` Alessio Balsini
2019-01-15 10:14 ` [PATCH v6 02/16] sched/core: uclamp: Extend sched_setattr() to support utilization clamping Patrick Bellasi
2019-01-15 10:15 ` [PATCH v6 03/16] sched/core: uclamp: Map TASK's clamp values into CPU's clamp buckets Patrick Bellasi
2019-01-21 10:15 ` Peter Zijlstra
2019-01-21 12:27 ` Patrick Bellasi
2019-01-21 12:51 ` Peter Zijlstra
2019-01-21 15:05 ` Peter Zijlstra
2019-01-21 15:34 ` Patrick Bellasi
2019-01-15 10:15 ` [PATCH v6 04/16] sched/core: uclamp: Add CPU's clamp buckets refcounting Patrick Bellasi
2019-01-21 14:59 ` Peter Zijlstra
2019-01-21 15:23 ` Patrick Bellasi
2019-01-21 16:12 ` Peter Zijlstra
2019-01-21 16:33 ` Patrick Bellasi
2019-01-22 9:45 ` Peter Zijlstra
2019-01-22 10:31 ` Patrick Bellasi
2019-01-21 15:17 ` Peter Zijlstra
2019-01-21 15:54 ` Patrick Bellasi
2019-01-22 10:03 ` Peter Zijlstra
2019-01-22 10:53 ` Patrick Bellasi
2019-01-15 10:15 ` [PATCH v6 05/16] sched/core: uclamp: Update CPU's refcount on clamp changes Patrick Bellasi
2019-01-21 15:33 ` Peter Zijlstra
2019-01-21 15:44 ` Patrick Bellasi
2019-01-22 9:37 ` Peter Zijlstra
2019-01-22 10:43 ` Patrick Bellasi
2019-01-22 13:28 ` Peter Zijlstra
2019-01-22 14:01 ` Patrick Bellasi
2019-01-22 14:57 ` Peter Zijlstra
2019-01-22 15:33 ` Patrick Bellasi
2019-01-23 9:16 ` Peter Zijlstra
2019-01-23 14:14 ` Patrick Bellasi
2019-01-23 18:59 ` Peter Zijlstra
2019-01-24 11:21 ` Patrick Bellasi
2019-01-24 12:38 ` Peter Zijlstra
2019-01-15 10:15 ` [PATCH v6 06/16] sched/core: uclamp: Enforce last task UCLAMP_MAX Patrick Bellasi
2019-01-15 10:15 ` [PATCH v6 07/16] sched/core: uclamp: Add system default clamps Patrick Bellasi
2019-01-22 13:56 ` Peter Zijlstra
2019-01-22 14:43 ` Patrick Bellasi
2019-01-22 15:13 ` Peter Zijlstra
2019-01-22 15:41 ` Patrick Bellasi
2019-01-23 9:22 ` Peter Zijlstra
2019-01-23 14:19 ` Patrick Bellasi
2019-01-23 19:10 ` Peter Zijlstra
2019-01-15 10:15 ` [PATCH v6 08/16] sched/cpufreq: uclamp: Add utilization clamping for FAIR tasks Patrick Bellasi
2019-01-22 10:37 ` Rafael J. Wysocki [this message]
2019-01-22 11:02 ` Patrick Bellasi
2019-01-22 11:04 ` Rafael J. Wysocki
2019-01-22 11:27 ` Patrick Bellasi
2019-01-22 15:21 ` Peter Zijlstra
2019-01-22 15:45 ` Patrick Bellasi
2019-01-22 17:13 ` Peter Zijlstra
2019-01-22 18:18 ` Patrick Bellasi
2019-01-23 9:52 ` Peter Zijlstra
2019-01-23 14:24 ` Patrick Bellasi
2019-01-15 10:15 ` [PATCH v6 09/16] sched/cpufreq: uclamp: Add utilization clamping for RT tasks Patrick Bellasi
2019-01-22 12:30 ` Quentin Perret
2019-01-22 12:37 ` Patrick Bellasi
2019-01-23 10:28 ` Peter Zijlstra
2019-01-23 14:33 ` Patrick Bellasi
2019-01-23 10:49 ` Peter Zijlstra
2019-01-23 14:40 ` Patrick Bellasi
2019-01-23 20:11 ` Peter Zijlstra
2019-01-24 12:30 ` Patrick Bellasi
2019-01-24 12:38 ` Patrick Bellasi
2019-01-24 15:12 ` Peter Zijlstra
2019-01-24 16:00 ` Patrick Bellasi
2019-01-24 15:31 ` Peter Zijlstra
2019-01-24 16:14 ` Patrick Bellasi
2019-01-24 15:33 ` Peter Zijlstra
2019-01-24 15:15 ` Peter Zijlstra
2019-01-24 16:05 ` Patrick Bellasi
2019-01-15 10:15 ` [PATCH v6 10/16] sched/core: Add uclamp_util_with() Patrick Bellasi
2019-01-23 13:33 ` Peter Zijlstra
2019-01-23 14:51 ` Patrick Bellasi
2019-01-23 19:22 ` Peter Zijlstra
2019-01-15 10:15 ` [PATCH v6 11/16] sched/fair: Add uclamp support to energy_compute() Patrick Bellasi
2019-01-22 12:13 ` Quentin Perret
2019-01-22 12:45 ` Patrick Bellasi
2019-01-22 13:29 ` Quentin Perret
2019-01-22 14:26 ` Patrick Bellasi
2019-01-22 14:39 ` Quentin Perret
2019-01-22 15:01 ` Patrick Bellasi
2019-01-22 15:14 ` Quentin Perret
2019-01-15 10:15 ` [PATCH v6 12/16] sched/core: uclamp: Extend CPU's cgroup controller Patrick Bellasi
2019-01-15 10:15 ` [PATCH v6 13/16] sched/core: uclamp: Propagate parent clamps Patrick Bellasi
2019-01-15 10:15 ` [PATCH v6 14/16] sched/core: uclamp: Map TG's clamp values into CPU's clamp buckets Patrick Bellasi
2019-01-15 10:15 ` [PATCH v6 15/16] sched/core: uclamp: Use TG's clamps to restrict TASK's clamps Patrick Bellasi
2019-01-15 10:15 ` [PATCH v6 16/16] sched/core: uclamp: Update CPU's refcount on TG's clamp changes Patrick Bellasi
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=3006911.57lVBuUGX3@aspire.rjw.lan \
--to=rjw@rjwysocki.net \
--cc=dietmar.eggemann@arm.com \
--cc=joelaf@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=patrick.bellasi@arm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=quentin.perret@arm.com \
--cc=rafael.j.wysocki@intel.com \
--cc=smuckle@google.com \
--cc=surenb@google.com \
--cc=tj@kernel.org \
--cc=tkjos@google.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
/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).