Messages in this thread | | | Date | Thu, 4 May 2023 16:23:28 +0100 | From | Qais Yousef <> | Subject | Re: [PATCH 1/1] sched: Consider CPU contention in frequency & load-balance busiest CPU selection |
| |
On 05/03/23 19:13, Dietmar Eggemann wrote: > On 29/04/2023 16:58, Peter Zijlstra wrote: > > On Thu, Apr 06, 2023 at 05:50:30PM +0200, Dietmar Eggemann wrote: > >> Use new cpu_boosted_util_cfs() instead of cpu_util_cfs(). > >> > >> The former returns max(util_avg, runnable_avg) capped by max CPU > >> capacity. CPU contention is thereby considered through runnable_avg. > >> > >> The change in load-balance only affects migration type `migrate_util`. > > > > But why, and how does it affect? That is, isn't this Changelog a wee bit > > sparse? > > Absolutely. > > I have compelling test data based on JankbenchX on Pixel6 for > sugov_get_util() case I will share with v2.
I am actually still concerned this is a global win. This higher contention can potentially lead to higher power usage. Not every high contention worth reacting to faster. The blanket 25% headroom in map_util_perf() is already problematic. And Jankbench is not a true representative of a gaming workload which is what started this whole discussion. It'd be good if mediatek can confirm this helps their case. Or for us to find a way to run something more representative. The original ask was to be selective about being more reactive for specific scenarios/workloads. If we can't make this selective we need more data it won't hurt general power consumption. I plan to help with that, but my focus now is on other areas first, namely getting uclamp_max usable in production.
Sorry for being cynical. I appreciate all the effort put so far to help find a sensible solution.
Thanks!
-- Qais Yousef
| |