Re: [PATCH 2/2] sched: Document Energy Aware Scheduling

From: Quentin Perret <quentin.perret@arm.com>
To: Juri Lelli <juri.lelli@redhat.com>
Cc: corbet@lwn.net, peterz@infradead.org, rjw@rjwysocki.net,
	mingo@redhat.com, morten.rasmussen@arm.com, qais.yousef@arm.com,
	patrick.bellasi@arm.com, dietmar.eggemann@arm.com,
	linux-doc@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] sched: Document Energy Aware Scheduling
Date: Fri, 18 Jan 2019 09:16:52 +0000	[thread overview]
Message-ID: <20190118091652.xn6iw52tccwh6vap@queper01-lin> (raw)
In-Reply-To: <20190117155117.GG14385@localhost.localdomain>

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