Hi Juri,

On Thursday 17 Jan 2019 at 16:51:17 (+0100), Juri Lelli wrote:

On 10/01/19 11:05, Quentin Perret wrote:

[...]

quoted

+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 ...

quoted

+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 ...

quoted

+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.


[...]

quoted

+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.


[...]

quoted

+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