Re: [RFC PATCH v2 5/6] sched/fair: Select an energy-efficient CPU on task wake-up

[Quentin Perret]

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 :-)