On 07-05-20, 19:09, Quentin Perret wrote: > Android is trying very hard to use a single kernel image (commonly > called Generic Kernel Image, or GKI), closely aligned with mainline, to > run on all Android devices regardless of the vendor. > > The GKI project intends to not only improve the status quo for Android > users directly (less fragmentation simplifies updatability), but also > to benefit upstream by forcing all vendors to agree on one common > kernel, that we push hard to be aligned with mainline. > > 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. > > Indeed, in practice, Android devices often ship with only one CPUFreq > governor enabled, and don't require any other that would simply waste > memory for no benefits. All CPUFreq governors can already be built as > modules with one notable exception: schedutil. Though popular in > Android, some devices do not use schedutil, which is why it would be > preferable to not have it unconditionally built in GKI. This series is > an attempt to solve this problem, by making schedutil tristate. > > While modularization is usually not something we want to see near the > scheduler, it appeared to me as I wrote those patches that the > particular case of schedutil was actually not too bad to implement. > We already have to support switching governors at run-time, simply > because userspace is free to do that, so the infrastructure for turning > sugov on and off dynamically is already there. Loading the code a little > later doesn't seem to make that a lot worse. > > Patches 01-05 refactor some code to break the few dependencies on > schedutil being builtin (notably EAS). Patches 06-12 export various > symbols that schedutil needs when compiled as a module. And finally, > patches 13-14 finish off the work by making the Kconfig tristate.
IMHO, you have over-broken the patches, like first two could be merged together and all exports could have been done in a single patch, etc. i.e. all related or similar changes together... Acked-by: Viresh Kumar <viresh.ku...@linaro.org> -- viresh