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