On Wed, 7 Nov 2018 at 18:02, Quentin Perret <quentin.per...@arm.com> wrote: > > 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.per...@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 ...
yes. I had this in mind too but we are also rebuilding sched_domain in this case and thought that everything could be changed at the same time > > > 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 for the explanation > > Thanks, > Quentin