Messages in this thread | | | Date | Tue, 10 Apr 2018 19:14:42 +0100 | From | Quentin Perret <> | Subject | Re: [RFC PATCH v2 5/6] sched/fair: Select an energy-efficient CPU on task wake-up |
| |
On Tuesday 10 Apr 2018 at 19:29:32 (+0200), Peter Zijlstra wrote: > On Fri, Apr 06, 2018 at 04:36:06PM +0100, Dietmar Eggemann wrote: > > + for_each_freq_domain(fd) { > > + unsigned long spare_cap, max_spare_cap = 0; > > + int max_spare_cap_cpu = -1; > > + unsigned long util; > > + > > + /* Find the CPU with the max spare cap in the freq. dom. */ > > + for_each_cpu_and(cpu, freq_domain_span(fd), sched_domain_span(sd)) { > > + if (!cpumask_test_cpu(cpu, &p->cpus_allowed)) > > + continue; > > + > > + if (cpu == prev_cpu) > > + continue; > > + > > + util = cpu_util_wake(cpu, p); > > + cpu_cap = capacity_of(cpu); > > + if (!util_fits_capacity(util + task_util, cpu_cap)) > > + continue; > > + > > + spare_cap = cpu_cap - util; > > + if (spare_cap > max_spare_cap) { > > + max_spare_cap = spare_cap; > > + max_spare_cap_cpu = cpu; > > + } > > + } > > + > > + /* Evaluate the energy impact of using this CPU. */ > > + if (max_spare_cap_cpu >= 0) { > > + cur_energy = compute_energy(p, max_spare_cap_cpu); > > + if (cur_energy < best_energy) { > > + best_energy = cur_energy; > > + best_energy_cpu = max_spare_cap_cpu; > > + } > > + } > > + } > > If each CPU has its own frequency domain, then the above loop ends up > being O(n^2), no?
Hmmm, yes, that should be O(n^2) indeed.
> Is there really nothing we can do about that?
So, the only thing I see just now would be to make compute_energy() smarter somehow. Today we compute the energy consumed by each frequency domain and then sum them up to get the system energy. We re-compute the energy of each frequency domain, even when it is not involved in the migration. In the case you describe, we will end up re-computing the energy of many frequency domains on which nothing happens every time we re-call compute_energy(). So there is probably something we could do by caching those values somehow.
Otherwise, on systems with 2 frequency domains (e.g. big.LITTLE), the current code should behave relatively well. And I think that covers a large portion of the real-world systems for which EAS is useful, as of today at least ... :-)
> Also, I > feel that warrants a comment warning about this. > > Someone, somewhere will try and build a 64+64 cpu system and get > surprised it doesn't work :-)
| |