Message-ID: <20181107170213.yapun7nk5rrjdf55@queper01-lin>
Date:   Wed, 7 Nov 2018 17:02:16 +0000
From:   Quentin Perret <quentin.perret@....com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "open list:THERMAL" <linux-pm@...r.kernel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Ingo Molnar <mingo@...hat.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Morten Rasmussen <morten.rasmussen@....com>,
        Chris Redpath <chris.redpath@....com>,
        Patrick Bellasi <patrick.bellasi@....com>,
        Valentin Schneider <valentin.schneider@....com>,
        Thara Gopinath <thara.gopinath@...aro.org>,
        viresh kumar <viresh.kumar@...aro.org>,
        Todd Kjos <tkjos@...gle.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        "Cc: Steve Muckle" <smuckle@...gle.com>, adharmap@...eaurora.org,
        Saravana Kannan <skannan@...eaurora.org>,
        pkondeti@...eaurora.org, Juri Lelli <juri.lelli@...hat.com>,
        Eduardo Valentin <edubezval@...il.com>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        currojerez@...eup.net, Javi Merino <javi.merino@...nel.org>
Subject: Re: [PATCH v8 03/15] PM: Introduce an Energy Model management
 framework

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@....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

Powered by blists - more mailing lists