Messages in this thread | | | Date | Tue, 19 Jun 2018 14:24:49 +0100 | From | Quentin Perret <> | Subject | Re: [RFC PATCH v3 05/10] sched/topology: Reference the Energy Model of CPUs when available |
| |
On Tuesday 19 Jun 2018 at 14:26:32 (+0200), Peter Zijlstra wrote: > On Mon, May 21, 2018 at 03:25:00PM +0100, Quentin Perret wrote: > > In order to use EAS, the task scheduler has to know about the Energy > > Model (EM) of the platform. This commit extends the scheduler topology > > code to take references on the frequency domains objects of the EM > > framework for all online CPUs. Hence, the availability of the EM for > > those CPUs is guaranteed to the scheduler at runtime without further > > checks in latency sensitive code paths (i.e. task wake-up). > > I'm confused by this patch,... what does it do? Why is em_cpu_get() > (after you fix it) not sufficient?
Hmm, so maybe the confusing part is that this patch does two things: 1. it checks all conditions for starting EAS are met (SD_ASYM_CPUCAPACITY is set, the EM covers all online CPUs, the EM isn't too complex to be used during wakeup); 2. it builds a list of frequency domains for the private use of the scheduler in latency sensitive code paths, and sets the static key
So I guess your question is more about 2. It is nice to have a list of frequency domains because that makes iteration over frequency domains in the wake-up path very easy, and efficient (for_each_freq_domain() is used in find_energy_efficient_cpu() and compute_energy(), patches 07 and 09/10). And also, by making the scheduler maintain that list, we can be more hotplug-aware. If you hotplug out all CPUs of a freq domain, the scheduler can remove it from its list and have one less element to iterate against. The idea was tp remove the unused things on hotplug, just like for sched domains.
I think that not having that list would mean to play with cpumasks in find_energy_efficient_cpu() and in compute_energy() to keep track of the CPUs we have visited and stuff like that. That's doable but probably more complex, and not more efficient, I think.
Is the overall idea any clearer ?
Thanks, Quentin
| |