Messages in this thread | | | Date | Fri, 8 May 2020 12:16:12 +0100 | From | Quentin Perret <> | Subject | Re: [PATCH 00/14] Modularize schedutil |
| |
On Friday 08 May 2020 at 12:37:21 (+0200), Greg KH wrote: > On Fri, May 08, 2020 at 10:11:28AM +0200, Peter Zijlstra wrote: > > On Thu, May 07, 2020 at 07:09:58PM +0100, Quentin Perret wrote: > > > One challenge to implement GKI is to avoid bloating the kernel by > > > compiling too many things in, especially given that different devices > > > need different things. As such, anything that can be turned into a > > > module helps GKI, by offering an alternative to having that component > > > built-in. This is true for pretty much anything that can be made > > > modular, including drivers as well as other kernel components, such as > > > CPUFreq governors. > > > > The idea is to move to 1 governor, schedutil. Also, I abhor all the > > exports this thing does. Modules have no business touching most of that. > > > > Look at every EXPORT you do and wonder ask yourself how you can abuse > > it. Modules are not a good thing, they're horrible pieces of crap. > > Quentin, what is missing from schedutil that warrants the need for a > totally different governor? Is there specific problems with the > existing ones or is this just an instance of "we wrote our own a long > time ago and never pushed it upstream" from various SoC companies?
In all honesty, this is probably a mix. Some vendors definitely have their out of tree crap that they'll load anyways, and some others use other mainline governors for semi-reasonable reasons (e.g, for lower tier devices, they often don't want to go though the costly and tedious process of tuning uclamp, so they'll go for a more 'aggressive' governor like ondemand). Note that this is the minority, though. The majority in Android use schedutil, and I'm quite happy with that.
However, the point I tried to make here is orthogonal to that. As of today using another governor than schedutil is fully supported upstream, and in fact it isn't even enabled by default for most archs. If vendors feel like using something else makes their product better, then I don't see why I need to argue with them about that. And frankly I don't see that support being removed from upstream any time soon.
Don't get me wrong, I do think schedutil is the way to go. And we do recommend it in Android. I'm simply saying that /mandating/ it in GKI would only add more friction than really necessary. Making it modular, OTOH, might ease things a bit.
I guess it all boils down to the code. If modularizing schedutil really is too ugly, then I'll drop the series and we'll just build it in and waste memory on devices that don't use it. It's not the end of the world, but it's a shame if we don't have strong technical reasons to do that -- all other governors _are_ modular.
IMO the changes in this series aren't *too* bad -- moving schedutil_cpu_util to fair.c is probably a sensible change in its own right for instance. The biggest 'issue' is probably the exports, but these will need discussions on a case by case basis. And I'm happy to try and rework the code to work around when possible (as is the case for runqueues for instance).
I hope that helps!
Thanks, Quentin
| |