From: Patrick Bellasi <patrick.bellasi@arm.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Quentin Perret <quentin.perret@arm.com>,
Thara Gopinath <thara.gopinath@linaro.org>,
linux-pm@vger.kernel.org,
Morten Rasmussen <morten.rasmussen@arm.com>,
Chris Redpath <chris.redpath@arm.com>,
Valentin Schneider <valentin.schneider@arm.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Todd Kjos <tkjos@google.com>, Joel Fernandes <joelaf@google.com>
Subject: Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up
Date: Wed, 21 Mar 2018 15:35:18 +0000 [thread overview]
Message-ID: <20180321153518.GC13951@e110439-lin> (raw)
In-Reply-To: <20180320094312.24081-6-dietmar.eggemann@arm.com>
On 20-Mar 09:43, Dietmar Eggemann wrote:
> From: Quentin Perret <quentin.perret@arm.com>
[...]
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 76bd46502486..65a1bead0773 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -6513,6 +6513,60 @@ static unsigned long compute_energy(struct task_struct *p, int dst_cpu)
> return energy;
> }
>
> +static bool task_fits(struct task_struct *p, int cpu)
> +{
> + unsigned long next_util = cpu_util_next(cpu, p, cpu);
> +
> + return util_fits_capacity(next_util, capacity_orig_of(cpu));
^^^^^^^^^^^^^^^^^^^^^
Since here we are at scheduling CFS tasks, should we not better use
capacity_of() to account for RT/IRQ pressure ?
> +}
> +
> +static int find_energy_efficient_cpu(struct sched_domain *sd,
> + struct task_struct *p, int prev_cpu)
> +{
> + unsigned long cur_energy, prev_energy, best_energy;
> + int cpu, best_cpu = prev_cpu;
> +
> + if (!task_util(p))
We are still waking up a task... what if the task was previously
running on a big CPU which is now idle?
I understand that from a _relative_ energy_diff standpoint there is
not much to do for a 0 utilization task. However, for those tasks we
can still try to return the most energy efficient CPU among the ones
in their cpus_allowed mask.
It should be a relatively low overhead (maybe contained in a fallback
most_energy_efficient_cpu() kind of function) which allows, for
example on ARM big.LITTLE systems, to consolidate those tasks on
LITTLE CPUs instead for example keep running them on a big CPU.
> + return prev_cpu;
> +
> + /* Compute the energy impact of leaving the task on prev_cpu. */
> + prev_energy = best_energy = compute_energy(p, prev_cpu);
> +
> + /* Look for the CPU that minimizes the energy. */
^^^^^^^^^^
nit-pick: would say explicitly "best_energy" here, just to avoid
confusion about (non) possible overflows in the following if check ;)
> + for_each_cpu_and(cpu, &p->cpus_allowed, sched_domain_span(sd)) {
> + if (!task_fits(p, cpu) || cpu == prev_cpu)
nit-pick: to me it would read better as:
if (cpu == prev_cpu)
continue;
if (!task_fits(p, cpu))
continue;
but it's more matter of (personal) taste then efficiency.
> + continue;
> + cur_energy = compute_energy(p, cpu);
> + if (cur_energy < best_energy) {
> + best_energy = cur_energy;
> + best_cpu = cpu;
> + }
> + }
> +
> + /*
> + * We pick the best CPU only if it saves at least 1.5% of the
> + * energy used by prev_cpu.
> + */
> + if ((prev_energy - best_energy) > (prev_energy >> 6))
> + return best_cpu;
> +
> + return prev_cpu;
> +}
[...]
> @@ -6555,6 +6613,14 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f
> break;
> }
>
> + /*
> + * Energy-aware task placement is performed on the highest
> + * non-overutilized domain spanning over cpu and prev_cpu.
> + */
> + if (want_energy && !sd_overutilized(tmp) &&
> + cpumask_test_cpu(prev_cpu, sched_domain_span(tmp)))
> + energy_sd = tmp;
> +
Not entirely sure, but I was trying to understand if we can avoid to
modify the definition of want_affine (in the previous chunk) and move
this block before the previous "if (want_affine..." (in mainline but
not in this chunk), which will became an else, e.g.
if (want_energy && !sd_overutilized(tmp) &&
// ...
else if (want_energy && !sd_overutilized(tmp) &&
// ...
Isn't that the same?
Maybe there is a code path I'm missing... but otherwise it seems a
more self contained modification of select_task_rq_fair...
> if (tmp->flags & sd_flag)
> sd = tmp;
> else if (!want_affine)
> @@ -6586,6 +6652,8 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f
> if (want_affine)
> current->recent_used_cpu = cpu;
> }
> + } else if (energy_sd) {
> + new_cpu = find_energy_efficient_cpu(energy_sd, p, prev_cpu);
> } else {
> new_cpu = find_idlest_cpu(sd, p, cpu, prev_cpu, sd_flag);
> }
--
#include <best/regards.h>
Patrick Bellasi
next prev parent reply other threads:[~2018-03-21 15:35 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-20 9:43 [RFC PATCH 0/6] Energy Aware Scheduling Dietmar Eggemann
2018-03-20 9:43 ` [RFC PATCH 1/6] sched/fair: Create util_fits_capacity() Dietmar Eggemann
2018-03-20 9:43 ` [RFC PATCH 2/6] sched: Introduce energy models of CPUs Dietmar Eggemann
2018-03-20 9:52 ` Greg Kroah-Hartman
2018-03-21 0:45 ` Quentin Perret
2018-03-25 13:48 ` Quentin Perret
2018-03-26 22:26 ` Dietmar Eggemann
2018-04-09 12:01 ` Peter Zijlstra
2018-04-09 13:45 ` Quentin Perret
2018-04-09 15:32 ` Peter Zijlstra
2018-04-09 16:42 ` Quentin Perret
2018-04-10 6:55 ` Rafael J. Wysocki
2018-04-10 9:31 ` Quentin Perret
2018-04-10 10:20 ` Rafael J. Wysocki
2018-03-20 9:43 ` [RFC PATCH 3/6] sched: Add over-utilization/tipping point indicator Dietmar Eggemann
2018-04-09 9:40 ` Peter Zijlstra
2018-04-09 9:47 ` Peter Zijlstra
2018-04-09 9:53 ` Dietmar Eggemann
2018-04-09 11:49 ` Peter Zijlstra
2018-03-20 9:43 ` [RFC PATCH 4/6] sched/fair: Introduce an energy estimation helper function Dietmar Eggemann
2018-03-21 9:04 ` Juri Lelli
2018-03-21 12:26 ` Patrick Bellasi
2018-03-21 12:59 ` Juri Lelli
2018-03-21 13:55 ` Quentin Perret
2018-03-21 15:15 ` Juri Lelli
2018-03-21 16:26 ` Morten Rasmussen
2018-03-21 17:02 ` Juri Lelli
2018-03-21 14:02 ` Quentin Perret
2018-03-21 21:15 ` Dietmar Eggemann
2018-03-21 12:39 ` Patrick Bellasi
2018-03-21 14:26 ` Quentin Perret
2018-03-21 14:50 ` Juri Lelli
2018-03-21 15:54 ` Patrick Bellasi
2018-03-22 5:05 ` Quentin Perret
2018-03-20 9:43 ` [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up Dietmar Eggemann
2018-03-21 15:35 ` Patrick Bellasi [this message]
2018-03-22 20:10 ` Joel Fernandes
2018-03-23 15:47 ` Morten Rasmussen
2018-03-24 1:13 ` Joel Fernandes
2018-03-24 1:34 ` Quentin Perret
2018-03-24 6:06 ` Joel Fernandes
2018-03-24 6:06 ` Joel Fernandes
2018-03-24 1:22 ` Quentin Perret
2018-03-25 1:52 ` Quentin Perret
2018-03-22 16:27 ` Joel Fernandes
2018-03-22 18:06 ` Patrick Bellasi
2018-03-22 20:19 ` Joel Fernandes
2018-03-24 1:47 ` Quentin Perret
2018-03-25 0:12 ` Joel Fernandes
2018-03-23 16:00 ` Morten Rasmussen
2018-03-24 0:36 ` Joel Fernandes
2018-03-25 1:38 ` Quentin Perret
2018-03-20 9:43 ` [RFC PATCH 6/6] drivers: base: arch_topology.c: Enable EAS for arm/arm64 platforms Dietmar Eggemann
2018-03-20 9:49 ` Greg Kroah-Hartman
2018-03-20 15:20 ` 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=20180321153518.GC13951@e110439-lin \
--to=patrick.bellasi@arm.com \
--cc=chris.redpath@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=joelaf@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=quentin.perret@arm.com \
--cc=rjw@rjwysocki.net \
--cc=thara.gopinath@linaro.org \
--cc=tkjos@google.com \
--cc=valentin.schneider@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.