On Tue, Jul 31, 2018 at 9:31 PM, <skan...@codeaurora.org> wrote: > On 2018-07-31 00:59, Quentin Perret wrote: >> >> On Monday 30 Jul 2018 at 12:35:27 (-0700), skan...@codeaurora.org wrote: >> [...] >>> >>> 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.
