Messages in this thread | | | From | Valentin Schneider <> | Subject | Re: [PATCH 00/14] Modularize schedutil | Date | Fri, 08 May 2020 15:52:07 +0100 |
| |
On 08/05/20 14:15, Quentin Perret wrote: > Hey Valentin, > > On Thursday 07 May 2020 at 22:34:17 (+0100), Valentin Schneider wrote: >> I'm curious; why would some Android device not want to roll with schedutil? >> >> When it comes to dynamic policies (i.e. forget performance / powersave, and >> put userspace in a corner), I'd be willing to take a stand and say you >> should only really be using schedutil nowadays - alignment with the >> scheduler, uclamp, yadda yadda. >> >> AFAIA the only schedutil-related quirk we oughta fix for arm/arm64 is that >> arch_scale_freq_invariant() thingie, and FWIW I'm hoping to get something >> regarding this out sometime soonish. After that, I'd actually want to make >> schedutil the default governor for arm/arm64. > > As in setting CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y in the arm64 > defconfig? If so, you have my Acked-by already :) >
I'm actually thinking of making it the unconditional default for arm/arm64 in cpufreq's Kconfig, following what has been recently done for intel_pstate.
>> I'm not opiniated on the modularization, but if you can, could you please >> share some more details as to why schedutil cannot fulfill its role of holy >> messiah of governors for GKI? > > I guess I answered some of that in the other thread with Peter, but all > in all I'm definitely not trying to make an argument that schedutil > isn't good enough here. I'm trying to say that mandating it in *GKI* is > just likely to cause unnecessary friction, and trust me there is already > enough of that with other topics.
Right, I appreciate it must be an "interesting" tug of war. My own opinion has also already been expanded in the rest of the thread; i.e. we should strive to make schedutil good enough that folks don't feel like they still need to use ondemand/whatever frankengov. That said, even without GKI, I get that making some vendors change their already tested-and-tuned setup is an obstacle course in and of itself.
> Giving the option of having sugov as a > module doesn't prevent us from making it a default for a few arches, so > I think there is ground for an agreement! > > Cheers, > Quentin
| |