Hey, the module's uclamp setting is not entirely beneficial (+ suggestion for a more optimized version) #34
Description
Hello, notzeeta. I came here to bring an issue showing that the uclamp setting you used in your module is not entirely beneficial for all cell phones.
The uclamp optimization you use tends to give too much priority to background processes unnecessarily.
The foreground is also greatly impaired + top-app could be improved even more.
A suggestion for an optimized uclamp that covers these factors is this:
Cgroup tweak for UCLAMP scheduler
Top-App
write /dev/cpuctl/top-app/cpu.uclamp.max max
write /dev/cpuctl/top-app/cpu.uclamp.min 20
write /dev/cpuctl/top-app/cpu.uclamp.latency_sensitive 1
Foreground
write /dev/cpuctl/foreground/cpu.uclamp.max 80
write /dev/cpuctl/foreground/cpu.uclamp.min 10
write /dev/cpuctl/foreground/cpu.uclamp.latency_sensitive 0
Background
write /dev/cpuctl/background/cpu.uclamp.max 40
write /dev/cpuctl/background/cpu.uclamp.min 0
write /dev/cpuctl/background/cpu.uclamp.latency_sensitive 0
System-App
write /dev/cpuctl/system-background/cpu.uclamp.max 50
write /dev/cpuctl/system-background/cpu.uclamp.min 0
write /dev/cpuctl/system-background/cpu.uclamp.latency_sensitive 0
this "renewable setting" of uclamp really takes advantage of uclamp efficiently.
The current uclamp settings you used gave very little potential to the foreground (which is essential for system responsiveness + tasks that cannot be allocated as top-app) and gave a lot to the background (which is known for being a cgroup that consumes much less resources, but the way you set it up gave it a lot of priority, which is counter-prudent for a module that focuses on optimization)
and note: maybe the path you used for uclamp is wrong, and only maybe, because in my kernel it is very different from the one you used in the module (but it could be because of my kernel, I don't know)