Thread (72 messages) 72 messages, 8 authors, 2018-08-12

Re: [PATCH v5 10/14] sched/cpufreq: Refactor the utilization aggregation method

From: "Rafael J. Wysocki" <rafael@kernel.org>
Date: 2018-08-01 07:32:53
Also in: lkml

On Tue, Jul 31, 2018 at 9:31 PM,  [off-list ref] wrote:
On 2018-07-31 00:59, Quentin Perret wrote:
quoted
On Monday 30 Jul 2018 at 12:35:27 (-0700), skannan@codeaurora.org wrote:
[...]
quoted
If it's going to be a different aggregation from what's done for
frequency
guidance, I don't see the point of having this inside schedutil. Why not
keep it inside the scheduler files?

This code basically results from a discussion we had with Peter on v4.
Keeping everything centralized can make sense from a maintenance
perspective, I think. That makes it easy to see the impact of any change
to utilization signals for both EAS and schedutil.

In that case, I'd argue it makes more sense to keep the code centralized in
the scheduler. The scheduler can let schedutil know about the utilization
after it aggregates them. There's no need for a cpufreq governor to know
that there are scheduling classes or how many there are. And the scheduler
can then choose to aggregate one way for task packing and another way for
frequency guidance.
Also the aggregate utilization may be used by cpuidle governors in
principle to decide how deep they can go with idle state selection.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help