[display] Add automatic cpu governor policy

[Michal-Szczepaniak]

I'm creating this PR to hopefully give this some traction. This functionality (because it was requested by me lol) would be really useful to me. UI on Motorola Moto X 2014 is super laggy, like 2x worse than jolla phone even, but if i set core0's minimum frequency to 1.2GHz it's smooth as butter so this patch would achieve doing that while screen is on and would help me a lot

@spiiroin's comment

MCE has cpu scaling governor feature that was meant to be used for
activating performance governor during bootup / shutdown and otherwise
select interactive governor. It was never taken in active use as is
was found to interfere with more advanced already existing android
side services. However - after fixing some obvious faults - having such
feature available might be useful for some device ports.

Make it possible to configure the following governor modes:

• performance - maximum performance
• interactive - high performance
• inactive - medium performance
• powersave - low performance

Implement policy that switches active governor based on device
state.

Utilize a run-time setting for:

• disabling the whole feature
• explicitly selecting one of the modes
• automatically switching between the modes depending on device state

Also provide:

• an annotated example configuration file
• python script for generating skeleton configuration files

Signed-off-by: Simo Piiroinen [email protected]

[spiiroin]

This approach has some drawbacks: hw specific config files are needed, coming up with such requires understanding of low level details, and when done it is likely that this will interfere with some already existing (android) mechanism causing unpredictable behavior / disabling of e.g. overheating mitigation logic.

An alternative approach could be: instead of directly writing to kernel control interfaces, the state evaluation logic here could be used for feeding hints to android performance manager (ref:https://source.android.com/devices/tech/power/performance). Which would be more generic solution and avoid interfering with thermal mitigation etc.

The code in here is rather old, was largely untested at the time of development, and thus at minimum would require some amount of rebasing and sanity checking. But preferably if/when merged, it should be in a state that does not place any obstacles in the way of utilizing it for the more generic solution described above / make already existing low level configuration files in active use defunct.

IOW I'd rather not merge this now / in the state it is.

[Thaodan]

This approach has some drawbacks: hw specific config files are needed, coming up with such requires understanding of low level details, and when done it is likely that this will interfere with some already existing (android) mechanism causing unpredictable behavior / disabling of e.g. overheating mitigation logic. An alternative approach could be: instead of directly writing to kernel control interfaces, the state evaluation logic here could be used for feeding hints to android performance manager (ref:https://source.android.com/devices/tech/power/performance). Which would be more generic solution and avoid interfering with thermal mitigation etc.

That would work only for hybris based adaptions, I think there should be a way to control this natively. Note: we don't use functionality such as libprocessgroup so far, also we disable similar things as cgroups on android side (this is visible in logcat when starting the camera on hybris based adaption).

[Michal-Szczepaniak]

This approach has some drawbacks: hw specific config files are needed, coming up with such requires understanding of low level details, and when done it is likely that this will interfere with some already existing (android) mechanism causing unpredictable behavior / disabling of e.g. overheating mitigation logic.

An alternative approach could be: instead of directly writing to kernel control interfaces, the state evaluation logic here could be used for feeding hints to android performance manager (ref:https://source.android.com/devices/tech/power/performance). Which would be more generic solution and avoid interfering with thermal mitigation etc.

The code in here is rather old, was largely untested at the time of development, and thus at minimum would require some amount of rebasing and sanity checking. But preferably if/when merged, it should be in a state that does not place any obstacles in the way of utilizing it for the more generic solution described above / make already existing low level configuration files in active use defunct.

IOW I'd rather not merge this now / in the state it is.

Same as @Thaodan mentioned, it would add dependency on android which is imo bad thing. And i don't mean using this to control governor and everything i only want to change minimum frequency, so it wouldn't bypass anything. Other solution would be to write some small program or kernel module to change it when screen is on/off so i kinda need to do it anyway and using mce imo would be best solution.

[spiiroin]

it would add dependency on android

No it would not. How it needs to be done is: common evaluation logic and possibility to choose one or another backend.

Which is almost as it is now, except that no time has been spent thinking about requirements of alternative backends. Which might easily lead to configuration means used by the current implementation becoming technical debt maintenance burden right from start.

[Thaodan]

> it would add dependency on android No it would not. How it needs to be done is: common evaluation logic and possibility to choose one or another backend.

I missread @spiirion's idea. He proposes to use cpuset to group for this instead of doing it ourself. This way the kernel does the setting of those tunings per process. We just need to make sure to disable/make the feature numb on the Android side for hybris-ports.

[Michal-Szczepaniak]

So seems like for my simple reason its better to write mce plugin or kernel module then

[Thaodan]

Cgroups are controlled by the userspace, the kernel just executes on them.

[Michal-Szczepaniak]

Just looked at latest commit and that seems to be spot on of what i needed!