On Friday 18 Jan 2019 at 12:20:57 (+0100), Rafael J. Wysocki wrote:

On Fri, Jan 18, 2019 at 12:11 PM Quentin Perret [off-list ref] wrote:

quoted

On Friday 18 Jan 2019 at 12:01:35 (+0100), Rafael J. Wysocki wrote:

quoted

On Fri, Jan 18, 2019 at 11:58 AM Rafael J. Wysocki [off-list ref] wrote:

quoted

On Fri, Jan 18, 2019 at 11:34 AM Quentin Perret [off-list ref] wrote:

quoted

Hi Rafael,

On Friday 18 Jan 2019 at 10:57:08 (+0100), Rafael J. Wysocki wrote:

quoted

On Fri, Jan 18, 2019 at 10:16 AM Quentin Perret [off-list ref] wrote:

quoted

Hi Juri,

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

quoted

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

[...]

quoted

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

But it won't hurt to mention that it may cover other scheduling
classes in the future.  IOW, the scope limit is not fundamental.

Agreed, I can do that.

quoted

quoted

quoted

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

Example sounds right.

You also can point to the section below from here.

Sounds good.

quoted

Side note: If the doc is in the .rst format (which Peter won't like
I'm sure :-)), you can actually use cross-references in it and you get
a translation to an HTML doc (hosted at kernel.org) for free and the
cross-references become clickable links in that.

Right, I personally don't mind the .rst format, but the existing files
in Documentation/power/ and Documentation/scheduler/ are good old txt
files so I just wanted to keep things consistent.

In fact, Documentation/power/ is under a slow on-going transition to
.rst (due to the benefits mentioned above).

quoted

I don't mind converting to rst if necessary :-)

It is not necessary, but maybe worth considering.

That said, as this is targeted at Documentation/scheduler/, being
consistent with the other material in there is probably more
important.

Right. Patch 01/02 is targeted at Documentation/power/ though. So if
that makes your life easier I can turn that one into a .rst file, no
problem at all.

Yes, I'd prefer it that way.  And please put it into
Documentation/driver-api/pm/.

Will do in v2.

Thanks,
Quentin