From: Quentin Perret <quentin.perret@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel <linux-kernel@vger.kernel.org>,
"open list:THERMAL" <linux-pm@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
Ingo Molnar <mingo@redhat.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Chris Redpath <chris.redpath@arm.com>,
Patrick Bellasi <patrick.bellasi@arm.com>,
Valentin Schneider <valentin.schneider@arm.com>,
Thara Gopinath <thara.gopinath@linaro.org>,
viresh kumar <viresh.kumar@linaro.org>,
Todd Kjos <tkjos@google.com>,
Joel Fernandes <joel@joelfernandes.org>,
"Cc: Steve Muckle" <smuckle@google.com>,
adharmap@codeaurora.org, Saravana Kannan <skannan@codeaurora.org>,
pkondeti@codeaurora.org, Juri Lelli <juri.lelli@redhat.com>,
Eduardo Valentin <edubezval@gmail.com>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
currojerez@riseup.net, Javi Merino <javi.merino@kernel.org>
Subject: Re: [PATCH v8 03/15] PM: Introduce an Energy Model management framework
Date: Wed, 7 Nov 2018 17:02:16 +0000 [thread overview]
Message-ID: <20181107170213.yapun7nk5rrjdf55@queper01-lin> (raw)
In-Reply-To: <CAKfTPtBN3HpNMrztcmAwkGuW9uHaKBi9KoqdvBEHuxf7=078NA@mail.gmail.com>
Hi Vincent,
On Wednesday 07 Nov 2018 at 17:32:32 (+0100), Vincent Guittot wrote:
> Hi Quentin,
>
> On Tue, 16 Oct 2018 at 12:15, Quentin Perret <quentin.perret@arm.com> wrote:
> >
>
> > +
> > +/**
> > + * em_pd_energy() - Estimates the energy consumed by the CPUs of a perf. domain
> > + * @pd : performance domain for which energy has to be estimated
> > + * @max_util : highest utilization among CPUs of the domain
> > + * @sum_util : sum of the utilization of all CPUs in the domain
> > + *
> > + * Return: the sum of the energy consumed by the CPUs of the domain assuming
> > + * a capacity state satisfying the max utilization of the domain.
> > + */
> > +static inline unsigned long em_pd_energy(struct em_perf_domain *pd,
> > + unsigned long max_util, unsigned long sum_util)
> > +{
> > + unsigned long freq, scale_cpu;
> > + struct em_cap_state *cs;
> > + int i, cpu;
> > +
> > + /*
> > + * In order to predict the capacity state, map the utilization of the
> > + * most utilized CPU of the performance domain to a requested frequency,
> > + * like schedutil.
> > + */
> > + cpu = cpumask_first(to_cpumask(pd->cpus));
> > + scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
> > + cs = &pd->table[pd->nr_cap_states - 1];
> > + freq = map_util_freq(max_util, cs->frequency, scale_cpu);
> > +
> > + /*
> > + * Find the lowest capacity state of the Energy Model above the
> > + * requested frequency.
> > + */
> > + for (i = 0; i < pd->nr_cap_states; i++) {
> > + cs = &pd->table[i];
> > + if (cs->frequency >= freq)
> > + break;
> > + }
> > +
> > + /*
> > + * The capacity of a CPU in the domain at that capacity state (cs)
> > + * can be computed as:
> > + *
> > + * cs->freq * scale_cpu
> > + * cs->cap = -------------------- (1)
> > + * cpu_max_freq
> > + *
> > + * So, ignoring the costs of idle states (which are not available in
> > + * the EM), the energy consumed by this CPU at that capacity state is
> > + * estimated as:
> > + *
> > + * cs->power * cpu_util
> > + * cpu_nrg = -------------------- (2)
> > + * cs->cap
> > + *
> > + * since 'cpu_util / cs->cap' represents its percentage of busy time.
> > + *
> > + * NOTE: Although the result of this computation actually is in
> > + * units of power, it can be manipulated as an energy value
> > + * over a scheduling period, since it is assumed to be
> > + * constant during that interval.
> > + *
> > + * By injecting (1) in (2), 'cpu_nrg' can be re-expressed as a product
> > + * of two terms:
> > + *
> > + * cs->power * cpu_max_freq cpu_util
> > + * cpu_nrg = ------------------------ * --------- (3)
> > + * cs->freq scale_cpu
> > + *
> > + * The first term is static, and is stored in the em_cap_state struct
> > + * as 'cs->cost'.
> > + *
> > + * Since all CPUs of the domain have the same micro-architecture, they
> > + * share the same 'cs->cost', and the same CPU capacity. Hence, the
> > + * total energy of the domain (which is the simple sum of the energy of
> > + * all of its CPUs) can be factorized as:
> > + *
> > + * cs->cost * \Sum cpu_util
> > + * pd_nrg = ------------------------ (4)
> > + * scale_cpu
> > + */
> > + return cs->cost * sum_util / scale_cpu;
>
> Why do you need to keep scale_cpu outside the cs->cost ? do you expect
> arch_scale_cpu_capacity() to change at runtime ?
Unfortunately yes, it can. It'll change at least during boot on arm64,
for example (see drivers/base/arch_topology.c). And also, userspace can
actually set that value via sysfs ...
> If the returned value of arch_scale_cpu_capacity() changes, we will
> have to rebuild several others things and we can include the update of
> cs->cost
Yeah, that was the original approach I had actually. Some of the older
versions of this patch set were doing just that. The only issue is that,
in order to make the cs->cost updatable are run time, you need to
introduce some level of protection around that data structure (RCU or
something). And that would make it a bit harder for IPA (for example) to
access the data -- it doesn't need any kind of RCU to access it's EM at
the moment.
We can probably do something a bit smarter and introduce RCU protection
only for the 'cost' field or something, but I was hoping that we could
keep things simple for now and do that kind of small optimization a bit
later :-)
Thanks,
Quentin
next prev parent reply other threads:[~2018-11-07 17:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-16 10:14 [PATCH v8 00/15] Energy Aware Scheduling Quentin Perret
2018-10-16 10:14 ` [PATCH v8 01/15] sched: Relocate arch_scale_cpu_capacity Quentin Perret
2018-10-16 10:15 ` [PATCH v8 02/15] sched/cpufreq: Prepare schedutil for Energy Aware Scheduling Quentin Perret
2018-10-16 10:15 ` [PATCH v8 03/15] PM: Introduce an Energy Model management framework Quentin Perret
2018-11-07 16:32 ` Vincent Guittot
2018-11-07 17:02 ` Quentin Perret [this message]
2018-11-07 18:02 ` Vincent Guittot
2018-10-16 10:15 ` [PATCH v8 04/15] PM / EM: Expose the Energy Model in sysfs Quentin Perret
2018-10-16 10:15 ` [PATCH v8 05/15] sched/topology: Reference the Energy Model of CPUs when available Quentin Perret
2018-10-16 10:15 ` [PATCH v8 06/15] sched/topology: Lowest CPU asymmetry sched_domain level pointer Quentin Perret
2018-10-16 10:15 ` [PATCH v8 07/15] sched/topology: Disable EAS on inappropriate platforms Quentin Perret
2018-10-16 10:15 ` [PATCH v8 08/15] sched/topology: Make Energy Aware Scheduling depend on schedutil Quentin Perret
2018-10-16 10:15 ` [PATCH v8 09/15] sched: Introduce sched_energy_present static key Quentin Perret
2018-10-16 10:15 ` [PATCH v8 10/15] sched: Introduce a sysctl for Energy Aware Scheduling Quentin Perret
2018-10-16 12:50 ` Juri Lelli
2018-10-16 13:36 ` Quentin Perret
2018-10-16 13:46 ` Juri Lelli
2018-10-16 10:15 ` [PATCH v8 11/15] sched/fair: Clean-up update_sg_lb_stats parameters Quentin Perret
2018-10-16 10:15 ` [PATCH v8 12/15] sched: Add over-utilization/tipping point indicator Quentin Perret
2018-10-16 10:15 ` [PATCH v8 13/15] sched/fair: Introduce an energy estimation helper function Quentin Perret
2018-10-16 10:15 ` [PATCH v8 14/15] sched/fair: Select an energy-efficient CPU on task wake-up Quentin Perret
2018-10-16 10:15 ` [PATCH v8 15/15] OPTIONAL: cpufreq: dt: Register an Energy Model Quentin Perret
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=20181107170213.yapun7nk5rrjdf55@queper01-lin \
--to=quentin.perret@arm.com \
--cc=adharmap@codeaurora.org \
--cc=chris.redpath@arm.com \
--cc=currojerez@riseup.net \
--cc=dietmar.eggemann@arm.com \
--cc=edubezval@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=javi.merino@kernel.org \
--cc=joel@joelfernandes.org \
--cc=juri.lelli@redhat.com \
--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=pkondeti@codeaurora.org \
--cc=rjw@rjwysocki.net \
--cc=skannan@codeaurora.org \
--cc=smuckle@google.com \
--cc=srinivas.pandruvada@linux.intel.com \
--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 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).