[HTC U11  ROMs, Kernels, Recoveries, & Other Develo] Freak07:
So allright guys. This will be the section where you will fine information on how to fine tune the EAS kernel if you aren´t satisfied with my default settings.

So as you can see in a kernel manager like EXKM for example we have an input boost on this kernel.

The 4 little cores ( aka the little cluster) gets boosted to 1171.200mhz for 1500ms when you interact/touch your screen by default.

This ensures scrolling/fling/app loading smoothness.

Now you say, only core 0 gets boosted. But if you look at the source you will see the cpu boost driver works only for both clusters and single cores. This is done by design.

If you want to additionally boost the big cluster (because you aren´t satisfied with above mentioned scrolling/fling/app loading etc) you have to define the boost frequency for core 4 also.

Writeup for dynamic stune boost v1 (OLD)

Now a writeup on dynamic stune boost by [MENTION=6745491]joshuous[/MENTION]

For those who are not sure what Stune (schedtune) boosting is, it is an EAS feature that allows you to bias frequencies higher or lower for certain task groups.

Android defines the following task groups that you can boost:

1. Top-app: The task that you're directly working on, or the task that you see. This mostly refers to the app that you're currently interacting with.

2. Foreground: Tasks that are not the top-app, but are still part of the user experience (e.g. the surfaceflinger display thread and audio threads)

3. Background: Tasks that are not part of the user experience (e.g. some random task running in the background that you don't care about)

4. System-background: Similar to background, but specifically for system tasks

5. Root: anything that else that does not belong to the other categories

Why do we need Schedtune boosting when we already have the cpu-boost feature?

cpu-boost works by allowing the user to set the specific boost frequencies and duration for clusters. But how do you know whether the frequency you specified is too little or too much? If you specify 1000 MHz boost for Little cluster, is that overkill for typing, or is it too miniscule for scrolling in a content-heavy app like Google Calendar? You end up facing a dilemma of choosing between increased battery drain or increased smoothness. Personally, I find that cpu-boost is rather inflexible and doesn't scale according to the user's needs.

So how does Schedtune boosting work?

Let's first talk about Schedutil governor. It works by using utilisation data provided by the [Linux] Completely Fair Scheduler. The 'CFS Scheduler' (not I/O scheduler erherm), in simple words, decides which tasks should be assigned to which CPU cores. Based on the Scheduler's knowledge of the tasks it allocates to cores, it can directly sends signals about the cores' utilisation to the Schedutil governor. Think of utilisation as the number of customers that a chef needs to serve at this point in time. The Schedutil governor uses the utilisation value and tells the chef how fast he must cook (what frequency the core should run at).

Now sometimes you may have certain customers (who are part of the Top-App Company) who are in a hurry to get their food and rush back to work. You need to serve the Top-App customers urgently, so you ask the chef to cook even faster than usual. You can think of Schedtune boosting as artificially inflating the number of customers (boosting the utilisation value) to get your chef to cook faster.

The beauty of Schedtune boosting over cpu-boost is that you don't need to fix a frequency to boost to. Instead, the Schedutil governor will give certain tasks a little bit more oomph. If the original unboosted frequency for scrolling is 600 MHz, Schedutil may boost it a little bit more to 750 MHz, for example. If the unboosted frequency for scrolling in calendar is 1000 MHz, perhaps Schedutil may boost it to 1300 MHz. It all depends on the boost value you want to set.

Give Schedtune boosting a go

Analogies aside, you can adjust the boost value in /dev/stune/{top-app, foreground, background, system-background}/schedtune.boost. Usually we mostly care about boosting top-app. Schedtune boost basically boosts the utilisation value by a certain factor. For example, if you set a boost value of 10, the utilisation (not the frequency) is boosted by 10%. A larger utilisation value will cause Schedutil to select a higher frequency.

Try setting the value in /dev/stune/top-app/schedtune.boost to a value between 10-20. Turn off cpu-boost. Enable GPU profile rendering and watch the magic. If your results are like mine, you'll see very low bars which means that it's really smooth. Launch CPU Float app and observe the frequencies. You might notice that they run at a very low frequency compared to the default cpu-boost value, yet it is even smoother. Why is Schedtune boosting producing smoother experience at a lower frequency? I have no freaking clue :S.

Now what is Dynamic Schedtune Boosting?

The issue with setting schedtune boosting (in /dev/stune/*) is that it boosts 24/7 and could drain a bit more battery. There are some situations when you may not want to boost, such as watching YouTube (Top-app task). Boosting is beneficial for mostly touch activity, such as scrolling or typing. The solution I implemented was extending the cpu-boost feature to apply schedtune boost only during touch activities. Other than touch events, schedtune boost won't run 24/7 and drain excess battery.

Getting started with Dynamic Stune Boost

To get started do the following:

1. Enable cpu-boost

2. Set all cpu-boost frequencies to zero

3. Set the boost duration to 1500ms (you can vary it depending on your needs)

4. Edit the boost value in /sys/module/cpu_boost/parameters/dynamic_stune_boost to between 10-20. Feel free to adjust this value. Make sure to set /dev/stune/top-app/schedtune.boost to 0, otherwise it may overwrite dynamic schedtune boost.

5. Turn on GPU Profile Rendering to analyse smoothness of frames.

6. Enjoy and report back your findings in terms of your tunable values, smoothness and battery drain.

tldr; If your brain hurts, just follow the instructions in "Getting started with Dynamic Stune Boost"

Now you may see that I don´t use the dynamic schedtune boost by default. That is because most tasks got assigned to the little cores when activating it and it actually performs worse. This will get solved in some time and I may update the guide then again.

But for now it is not recommended to turn on the dynamic stune boost.

Current setting are

dev/stune/schedtune.boost is at 5

dev/stune/top/app/schedtune.boost is at 15.

input boost is enabled for the little cluster (core 0) at 1171.200mhz for 1500 ms

If you want to experiment with different schedtune.boosts for global, background, foreground and top-app and found good values please share them with us here in the thread :)

A workaround for you experiment guys that want to enable the dynamic schedtune boost is:

1. Set /dev/stune/top-app/schedtune.boost to 5-10

2. Set dynamic stune boost to 10-20 (I like 20)

The issue with dynamic stune boost is that it only (at the moment) boosts the frequencies of the cluster that a top-app task resides in. So why were there still performance issues? That's because top-app tasks preferred to stay on Little cores, which is likely overcrowded already. That means that the top-app task have to compete with the other tasks on the same overcrowded core for computing power. Imagine it like having a huge pizza (high frequency), but so many people have to share it such that you only get a tiny piece. This is why a task can run on the less-crowded Big cluster at a much lower frequency but still perform better than running on a crowded Little cluster with high frequency.

Now, setting the /dev/stune/top-app/schedtune.boost to 5 does two things. Firstly, it increases the perceived load of the individual top-app task, consequently biasing Schedutil to select a higher frequency (not by much). Secondly and most importantly, since the perceived load is higher (imagine a very hungry person), EAS decides that it needs to be shifted to the Big cluster (larger pizza). 5 was chosen because it's around the tipping point to cause the shift. Use 10 if it's not smooth enough.

Dynamic stune boost doesn't influence tasks to be shifted to the Big cluster, which is why top-app tasks tended to stay on Little cluster.

Combining both steps, we can influence top-app tasks to run on Big cluster (step 1), and a larger Dynamic Stune Boost value will cause the frequency to ramp up during touch interactions on the Big cluster where top-app tasks run (step 2). No unnecessary boosting when watching YouTube woohoo!

Tldr; You're in a pizzeria. Regular schedtune boost shifts you to a less crowded table. Dynamic schedtune boost increases the size of your pizza. Your stomach rejoices

Writeups about dynamic schedtune boost v2 from [MENTION=5060769]Mostafa Wael[/MENTION] and [MENTION=6745491]joshuous[/MENTION]

Dynamic SchedTune Boosting v2

Couple of weeks ago, Joshuous wrote a new feature, namely Dynamic SchedTune Boosting, that’s been incorporated in recent RenderZenith kernel builds, which essentially alters the value of schedtune.boost for the top-app cgroup dynamically on touch events, to conserve battery. But still, the solution was not that flawless, since it didn’t migrate the task to the big cores when essential as Joshuous previously explained. A quick workaround was to increase the value of /dev/stune/top-app/schedtune.boost to 1 (at least) to allow the utilization of the big cores when required. Many of you may be wondering why that was necessary. Well, hopefully I can break it down a bit for you.

Given the task that needs processing, the find_best_target() function – that is responsible for placing the tasks on the suitable cluster – iterates firstly on the big cluster when the SchedTune boost value is greater than 0, whereas the little cluster will be iterated firstly, should the value of SchedTune boost be equal to or less than 0, to save power. What SchedTune boost does is inflating the task and CPU utilisation fed to the scheduler, and therefore impacting the OPP selection and allowing the task to be placed on the big core(s) if needed. What the older version of Dynamic SchedTune Boosting did was rather inflating the value of utilisation going into Schedutil governor, that is then used to determine the frequency step to be selected for the task via a linear formula, which consequently increases the calculated frequency. But since the value of utilisation going into the scheduler is not inflated, the placement of the task on the corresponding core(s) won’t be impacted and therefore, the task won’t be moved to a big core instead. In essence, the older version would only increase the frequency and not impact the tasks placement on the cores. This caused a drastic performance difference compared to what you get when setting the SchedTune Boost value statically.

With the new v2 version, Dynamic SchedTune Boosting will directly change the value of /dev/stune/top-app/schedtune.boost directly, addressing the issue of only inflating the utilisation data going to the schedutil governor, and therefore the tasks should be able to move to the big cluster when demanded as well as increasing the CPU frequency. This will allow us to safely leave the value of /dev/stune/top-app/schedtune.boost at 0 and save some power for low-medium workload scenarios, since the tasks will be moved to the big cluster on touch with no issues.

-TDK

with a little addition from [MENTION=6745491]joshuous[/MENTION]

Very well explained Mostafa

And thanks for saving me the time

To add on, don't be alarmed to see /dev/stune/top-app/schedtune.boost having the same value as dynamic_stune_boost when you want to edit it because your touches trigger the boosting. Just write the value you want into the file and save. It will automatically update the default stune boost value when the boosting stops. To confirm it, you can connect your phone to computer and do

adb shell cat /dev/stune/top-app/schedtune.boost

to confirm that it has changed. You gotta wait a second or so before you issue that command.

I would recommend keeping the /dev/stune/top-app/schedtune.boost at 1 or higher if you want lower latency when Dynamic Stune Boost kicks in. Reason being that default stune boost of 1 somewhat ensures that most of the top-app tasks are already on Big cluster so that we don't have to suddenly migrate too many tasks from Little to Big when Dynamic Stune Boost kicks in.

If you don't type much, and watch videos or listen to music mostly, then setting default stune boost to zero may save you more battery

following this link you will also find a goog explanation on how things work with EAS. It is quite simplified but good to get the general idea of it.

https://xdaforums.com/showpost.php?p=74054394&postcount=526