[Xiaomi Mi 6 Guides, News, & Discussion] cn.fyodor:
Hi, there

EAS kernel (mainly Energy Aware Scheduler) was firstly proposed by ARM few years ago and nowadays used more widely in custom ROM, although the OEMs didn't support it. The main obstacle of developing EAS kernel is the busy-cost-data for a specified CPU. Fortunately, Pixel 2 uses the same CPU as our XiaoMi 6 and Google shared the data in AOSP. Developers can directly use it for sagit. But EAS is not just a piece of data, we need drivers to make it work better for us.

The CPU scheduler supported in EAS is the famous /schedutil/ governor. This governor is unique and very different from others that it handles the frequencies based on system load. In our sagit kernel, there are already WALT (Window Assistant) codes left by Codeaurora, which can be used to predict the system load. So far, everything seems ready except of boosting things.

SchedTune was born for that. It creates 5 cgoups for different kinds of tasks, one of which is the /top-app/. Settings for this group will significantly affect the user experience. However, AFAIK, there are still no applications in userspace to control the interface, aka /schedtune.boost/. Its value can be altered from 0 to 100. Kernel developers often hard-coded some values to trigger the boost action. But /top-app/ should not be boosted forever. For example, if you're watching a video or listening some music, boost is not preferred for such sustainable tasks. To solve this issue, Joshuous introduced a mechanism call "Dynamic SchedTune Boost", see Ref. It dynamically set the boost for each cgroup task using slot-based tracking system. It is perfect in itself. But if we go through all boost techniques in the kernel, a giant of coupling system will appear and disturb our mind.

Let me try to sort it out.

In the original kernel released by XiaoMi, there are already a few boosting methods implemented by QCOM. Boosting inerface is created and coorperated with performance daemon in userspace. The first one is /proc/sys/kernel/sched_boost. The value is received from a daemon and afterwards triggers a bunch of tasks in the kernel. Codes for these tasks are deeply embedded in HMP, which for now seems impossible to coexist with EAS. To save this interface, Josh again wrote a stub function to build a connection between this interface and boost in schedtune, but he didn't count the value of sched_boost, which was defined from 0 to 3. The problem here becomes simple that we shall map [0 3 2 1] to [0..100]. Thus, I made an effort to write down a function as follows:

return data > 0 ? (4 - data) * 33 : 0;

The factor 33 is trivial and can be changed as you wish. I take 5 for conservative boosting. The returned value is then directly written to the interface /schedtune.boost/ for /top-app/. A positive side effect is that the code can naturally switch on/off the boost status.

The second boost is carried out by codes in soc/qcom/msm_performance.c, which set min/max CPU frequencies upon user touch. Do you remember the original idea behind the /interactive/ CPU governor? xD It's a bit annoying to pull-up the min frequencies constantly in background and waste energy. It seems safe to partially disable this boost in the kernel and just reserve the sysfs name.

The last one locates in cpu-boost.c, cooperated with HMP codes to boost CPU based on event notifier. Totally disable this feature.

After reviewing all boost techniques, we know that CPU frequency is no doubt most critical factor of all. I don't know why QCOM implemented so many boosts, even coupled with each other. I know that msm8998 performs very well without them. I build an experimental EAS kernel, driven by a combination of /schedutil/ and /schedtune/. Tested few days in a small community, it is running good with respect to power efficiency.

Kernel Source

Sorry, no prebuilt kernel here, just sharing the idea about EAS and boost.