Hi Juri, On Thursday 17 Jan 2019 at 16:51:17 (+0100), Juri Lelli wrote: > On 10/01/19 11:05, Quentin Perret wrote: [...] > > +The idea behind introducing an EM is to allow the scheduler to evaluate the > > +implications of its decisions rather than blindly applying energy-saving > > +techniques that may have positive effects only on some platforms. At the same > > +time, the EM must be as simple as possible to minimize the scheduler latency > > +impact. > > + > > +In short, EAS changes the way CFS tasks are assigned to CPUs. When it is time > > Not sure if we want to remark the fact that EAS is looking at CFS tasks > only ATM. Oh, what's wrong about mentioning it ? I mean, it is a fact ATM ... > > +for the scheduler to decide where a task should run (during wake-up), the EM > > +is used to break the tie between several good CPU candidates and pick the one > > +that is predicted to yield the best energy consumption without harming the > > +system's throughput. The predictions made by EAS rely on specific elements of > > +knowledge about the platform's topology, which include the 'capacity' of CPUs, > > Add a reference to DT bindings docs defining 'capacity' (or define it > somewhere)? Right, I can mention this is defined in the next section. But are you sure about the reference to the DT bindings ? They're arm-specific right ? Maybe I can give that as an example or something ... > > +and their respective energy costs. > > + > > + > > +3. Topology information > > +----------------------- > > + > > +EAS (as well as the rest of the scheduler) uses the notion of 'capacity' to > > +differentiate CPUs with different computing throughput. The 'capacity' of a CPU > > +represents the amount of work it can absorb when running at its highest > > +frequency compared to the most capable CPU of the system. Capacity values are > > +normalized in a 1024 range, and are comparable with the utilization signals of > > +tasks and CPUs computed by the Per-Entity Load Tracking (PELT) mechanism. Thanks > > +to capacity and utilization values, EAS is able to estimate how big/busy a > > +task/CPU is, and to take this into consideration when evaluating performance vs > > +energy trade-offs. The capacity of CPUs is provided via arch-specific code > > +through the arch_scale_cpu_capacity() callback. > > Ah, it's here, mmm, maybe still introduce it before (or point here from > above) and still point to dt bindings doc? Yep, I'll add a pointer above. [...] > > +the most energy efficient CPUs of the system more than the others if that can be > > +done without harming throughput. So, the load-balancer is disabled to prevent > > Load-balancing being disabled in EAS mode it's quite an important thing > to notice IMHO. Maybe state it clearly somewhere above? Right, this needs to be emphasized more. I'll mention it in the introduction. [...] > > +So, in order to use EAS on your platform your architecture must implement the > > Mmm, using 'your' form is a change of 'style', no? Good point, I will try to unify this section with the rest of the doc. There are loads of 'your platform' below too. Thank you very much for the typos as well :-) Quentin
