[10][KERNEL][06.12.2019] Kirisakura-Harmony-PIE 10.1.0 [3.18.140]

4,383 posts
Thanks Meter: 13,680
By Freak07, Senior Member on 19th February 2017, 05:44 PM
Post Reply Email Thread
Hey guys and girls,

I don´t have time to maintain 2 threads. Look in the Pixel XL forums.

Link is here:
The Following 15 Users Say Thank You to Freak07 For This Useful Post: [ View ] Gift Freak07 Ad-Free
19th February 2017, 05:45 PM |#2  
Freak07's Avatar
OP Senior Member
Thanks Meter: 13,680
So this post will be dedicated to information about EAS in general.

here is a good summary which also goes into detail regarding sched and schedutil.

Another amazing write up about alucardsched by a talented new dev @joshuous:

This is what I understand from tracing the Alucardsched code. I apologise if my understanding is incorrect.

Firstly, next frequency selection with Schedutil (very simple):
next_freq = 1.25 * Max_freq * current_util / max_util;
Now, here's a quick overview of one cycle of frequency selection in Alucardsched:
1. You have two key extra tunables: PUMP_INC_STEP and PUMP_DEC_STEP
2. Current utilisation here refers to the system's current demand. It is calculated using:
curr_util = (util * (100 + tunables->boost_perc)) / max_utilisation
The "util" is a value determined by the EAS scheduler.
3. Target load here refers to what processor is currently supplying. It is calculated using:
target_load = (current_freq * 100) / max_freq;
4. The key idea is to ensure that supply satisfies demand. That is, target load ≈ current load.
5. If target_load <= current_load (too little supply), then we want to increase frequencies to match the system’s load. For Alucardsched, frequency is increased by jumping up PUMP_INC_STEP number of steps in the OPP table. (By OPP table, I refer to the available frequencies that you can switch to)
6. If target_load > current_load (too much supply), then we want to decrease frequencies to match the system’s load. For Alucardsched, frequency is decreased by jumping down PUMP_DEC_STEP number of steps in the OPP table.
7. Do note that Alucardsched jumps several frequency steps, compared to Schedutil and Interactive which try to jump immediately to a calculated next frequency. In this way, Alucardsched doesn't care about the specific value of the next speed. It's like driving a car, and deciding to increase gears by several steps instead of deciding to jump immediately to a specific gear.

Extra Tunables
Sometimes you want the "pumping" behaviour to behave differently at lower and higher frequencies. FREQ_RESPONSIVENESS can be seen as the mark that divides the low and high frequencies. If the current frequency is less than FREQ_RESPONSIVENESS, the number of frequency skips will be PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ instead of the usual PUMP_INC_STEP and PUMP_DEC_STEP.

How is it used? If your frequency is low (lower than FREQ_RESPONSIVENESS) and your system demand is high, you ideally want to boost frequency speeds quickly. This is when PUMP_INC_STEP_AT_MIN_FREQ kicks in. PUMP_INC_STEP_AT_MIN_FREQ is usually (and should be) a larger value than PUMP_INC_STEP. When your frequency is high (higher than FREQ_RESPONSIVENESS) and your system demand is high, you don't want to be jumping so many steps up otherwise you will hit max frequencies too quickly (overkill). I'm pretty sure you can figure out how PUMP_DEC_STEP and PUMP_DEC_STEP_AT_MIN_FREQ works after having read this paragraph

Schedutil: simpler
Alucardsched: more tunable
PUMP_INC_STEP_AT_MIN_FREQ should be larger than PUMP_INC_STEP.

Note: There is however a potential problem (if you may call it one) with Alucardsched: just like Interactive you rely almost entirely on heuristics (trial and error) to control your frequency jumps instead of letting the system choose it for you, like in Schedutil. In that way, Alucardsched detracts from the goal of Schedutil to provide a simple frequency choosing mechanism. Without the proper tuning to meet your specific usage, it is likely that your frequencies will overshoot or undershoot past the needed load on Alucardsched (just like in Interactive). I would recommend that you play with the tunables to see what works best for you.

Here is information about energy-dcfc (Dynamic Capacity and Frequency Capping):

This new governor is based on schedutil. It uses target_load variables as thresholds to let the governor decide when to cap the frequencies for both clusters. These variables are called "load1_cap" and "load2_cap". Load1_cap corresponds to target_load1 meaning anything that is below target_load1, it caps using load1_cap. Anything above target_load1 and below target_load2, use load2_cap. Anything above target_load 2 and the maximum frequency will be used.

As a result of this behaviour, bit shift value must be set to 1. Anything higher than 1 and frequency scaling will be extremely slow. This is because the lower the maximum frequency, the lower the next frequency target is because the frequency range is being limited.

AS OF V009: The governor has now incorporated @Kyuubi10 's schedutil dynamic formula change. When load is below target_load1 it will use add bitshift in the formula. If load is above target_load1 but below target_load2, it won't use any bit shifting at all. If load is more than target_load2, it will subtract bitshift in the formula. This has proven to be very efficient with a touchboost-like behaviour when scrolling (Up to the capped frequency of this governor), then steady performance in between, and on heavy workloads it will not just stay on maximum frequency, in fact it will hover around 1.3-1.9GHz to ensure thermals are good as well as battery endurance.

This governor is aimed with maximum efficiency in mind. Do not expect outstanding performance with this governor.

helix_schedutil explained by @Kyuubi10

To understand Helix_schedutil you must first understand the original schedutil algorithm.
Here it is:
next_freq = maxfreq + (maxfreq >> bitshift) * util/maxcapacity

The most obvious difference of this algorithm is that it moves away from the idea of scaling frequencies up or down which were used in previous generations of governors.
Instead the aim of the above algorithm is to calculate the most appropriate frequency for the TOTAL CPU load.
NOTE: This is TOTAL load on CPU, not just load for the current frequency step as Interactive used to calculate with.

Now, for you numberphiles like myself that like understanding algorithms... Let's break it down:

"util/maxcapacity = Load."
The above creates a percentage value in decimal format (80% = 0.8) which represents the TOTAL load on CPU.
the algorithm now reads the following way:
next_freq = maxfreq + (maxfreq >> bitshift) * load

"maxfreq + (maxfreq >> bitshift)"

Essentially the aim of the above is to ensure that next_freq is always a little higher than the exact value needed to cover the load.

Bitshift: (paraphrasing @ZeroInfinity) in programming the ">>" mathematical function allows for shifting the binary values towards the direction of the arrows by "N" times.
In this case it is towards the right.

The relationship between "N" and the calculation in the "()" is as follows:
Bitshift = 1 = maxfreq/2
Bitshift = 2 = maxfreq/4
Bitshift = 3 = maxfreq/8

If the "+()" didn't exist in the algorithm, the chosen frequency would be exactly enough to cover the load.
If load is 0.6, aka 60%, all you need is a frequency = 60% of max frequency.
This would be bad since it doesn't leave any capacity/bandwidth leftover for inevitable bumps in load, nor space for EAS itself to run. Thus inevitably creating lags.
To keep a bit of free bandwidth you add "(maxfreq >> bitshift)".

Finally the problem I encountered, if bitshift = 2, then the result of the algorithm is that any load above 0.8 will result in a next_freq HIGHER than maxfreq. - This is your tipping point. As any load higher than 80% will wake up a new CPU.

Which means you have still about 20% of the CPU's max capacity being unused. Such a CPU is only 80% efficient.

Therefore by increasing bitshift to 3, the algorithm reads:
"maxfreq+(maxfreq/8)*load = next_freq"
This way you can use 89% of capacity before reaching max frequency of the CPU.
With bitshift=4 it reads:
"maxfreq+(maxfreq/16)*load = next_freq"
This allows you to use up to 94% total CPU load before reaching max frequency.
While this is great for improving efficiency at the higher frequencies, it doesn't leave enough bandwidth when calculating lower frequencies, and creates lag when load spikes at lower frequencies.

Update to the explanation:

After being inspired by the concept of @ZeroInfinity's new governor - Energy-DCFC, I decided to carry out a couple of tests on HTC 10 using variations of Helix_Schedutil.
The focus was stress-testing by increasing the current frequency load above 100%. (AKA Use up all of the bandwidth of the current frequency step.)
After the testing me and Zero worked on this new version of Helix_Schedutil.

The current behaviour of the governor is the following:
- Boost frequencies when load is below Target_Load1. (Boost can be increased by DECREASING bit_shift1 value.)
- Between Target_Loads there is no bit_shift at all. The governor just uses the following algorithm instead - (max_freq*util/max = next_freq)
- Loads higher than Target_Load2 will be THROTTLED. Bit_Shift2 here is subtracted rather than added. (Throttle effect can be increased by DECREASING bit_shift2 value.)

The result is that low freqs have spare bandwidth to avoid lags, middle frequencies leave no extra bandwidth at all, while higher frequencies are throttled to save battery.
Another focus of the governor update is to reduce overhead as much as possible. This results in a very responsive governor which isn't overly demanding on battery life.
Schedtune.boost values recommended for use with this governor:
Top_App: 5
Foreground: -50
Background: -50
Global: -50

Energy-DCFC is still recommended for those who prefer battery life over performance, but if you prefer greater performance then this governor can be used without making you feel guilty about wasting battery.

correction a misconception:
Some people describe tipping point as the load threshold which the governor uses to decide whether to ramp up or down.

While if you look into the behaviour of the governor it may appear that it behaves in such a way, it is technically incorrect.

As I mentioned previously this new algorithm moves away from the behaviour of legacy governor algorithms which focus on the current frequency load.
This governor does no ramping up or down.
It isn't even aware of the current frequency load, as it only knows the load relative to max capacity.

The misconception appears based on a property of the algorithm that results in a consistent load at any chosen frequency. This is a coincidental result of the algorithm, even though the algorithm is completely unaware of it.

Tipping point is in fact the load percentage at which the CPU reaches max frequency and any increase in load forces it to wake up a new core

here is some Information about pwrutil governor:

This new governor is based on schedutil.

A much simpler yet very effective governor based on schedutil. All this changes is the calculation to get the next frequency. Rather than using bit shift to calculate tipping point and what not, we don't use it at all. This is much much more efficient if you use my program called "schedutilCalculator" to calculate what the next frequency is. For example, a load of 25% with a max freq of 2150400 will get 500MHz as next frequency. A load of 50% will get 1GHz as next frequency. A load of 75% will get 1.5-1.6GHz as next frequency. A load of 100% will get 2.15GHz as next frequency. You can see the lower the load, the much lower the frequency selection will be, but the higher the load and the higher the frequency selection is. So it can go from a very low powered state with 50% load and under, to a high performance state from 75% load and above.

Includes a tunable called "utilboost" which is basically a load multiplier - it makes load higher than it is perceived by the governor, thus making next frequency selection higher. Remember utilisation does not equal load. The equation of calculating load is util / max capacity of a CPU (which should be 1024). So 512 / 1024 = 0.5 (50% load).

Util boost is supposed to be a replacement of schedtune.boost. schedtune.boost applies boosting to both clusters, whereas util boost allows boosting per-cluster so users can have much more control.
The Following 2 Users Say Thank You to Freak07 For This Useful Post: [ View ] Gift Freak07 Ad-Free
19th February 2017, 05:45 PM |#3  
Freak07's Avatar
OP Senior Member
Thanks Meter: 13,680
how to gather logs:

There are several apps that can do this process for you, Here is one: PlayStore: SysLog
And here is another: PlayStore: Andy Log (ROOT)

ramopps: is an oops/panic logger that writes its logs to RAM before the system
crashes. It works by logging oopses and panics in a circular buffer. Ramoops
needs a system with persistent RAM so that the content of that area can
survive after a restart.
logcat: the logoutput of the Android system
kernel log: (kmsg / dmesg): the kernel messages
Additionally there's the last_kmsg which is a dump of the kernel log until the last shutdown.
radio log: the log outpur ot your System / BB / RIL communication

ramopps:Some Documentation on Ramopps

Normal Logcat:

Radio Logcat:


Via adb:
adb shell su -c cat /sys/fs/pstore/console-ramoops > kmsg.txt

Via terminal on phone:

cat /sys/fs/pstore/console-ramoops > /sdcard/kmsg.txt

Kernel Log:

Kernel Log:
adb shell su -c dmesg > dmesg.log

New location of last_kmsg on Android 6.0 and above: /sys/fs/pstore/console-ramoops
adb shell su -c "cat /proc/last_kmsg" > last_kmsg.log

-v time will include timestamps in the logcats
-d will export the complete log.
If you want to save a continuous log you can remove the -d parameter - then you need to cancel the logging process via CTRL+C.
To export a continuous kernel log use adb shell su -c "cat /proc/kmsg" > dmesg.log (and cancel it via CTRL+C again).

PS: This Document was taked from another XDA Thread Called: [Reference] How to get useful logs
Also check this one out: [Tutorial] How To Logcat

I only Revived it a bit for ramopps.
I will update this more at a later time..
19th February 2017, 08:56 PM |#4  
Senior Member
Thanks Meter: 60
Attemped install on Pixel, ended up with black screen after white "unlocked booloader screen" had to reinstall system and custom rom.
19th February 2017, 09:15 PM |#5  
Freak07's Avatar
OP Senior Member
Thanks Meter: 13,680
Well it was confirmed working before.

Did anybody else flashed it successfully? And please follow my instructions in the op.
19th February 2017, 09:35 PM |#6  
crossen0's Avatar
Senior Member
Flag Kansas City
Thanks Meter: 226
Originally Posted by Freak07

Well it was confirmed working before.

Did anybody else flashed it successfully? And please follow my instructions in the op.

It worked for me by following instructions in the OP
The Following User Says Thank You to crossen0 For This Useful Post: [ View ] Gift crossen0 Ad-Free
19th February 2017, 09:36 PM |#7  
Keasby's Avatar
Senior Member
Thanks Meter: 178
Followed the instructions from OP, works fine for me!
Thanks for your works, try it out now
The Following User Says Thank You to Keasby For This Useful Post: [ View ] Gift Keasby Ad-Free
19th February 2017, 09:49 PM |#8  
shindiggity's Avatar
Senior Member
Flag San Diego
Thanks Meter: 1,171
Originally Posted by ne0ns4l4m4nder

Attemped install on Pixel, ended up with black screen after white "unlocked booloader screen" had to reinstall system and custom rom.

Working fine here following OP, thanks for another Kernel brotha!!
20th February 2017, 05:14 AM |#9  
Senior Member
Thanks Meter: 42
so idoes this kernal work better in lineage ROMS like hexa and Resurrection Remix v5.8.1 Roms ???
20th February 2017, 06:40 AM |#10  
Freak07's Avatar
OP Senior Member
Thanks Meter: 13,680
Originally Posted by abunhyan

so idoes this kernal work better in lineage ROMS like hexa and Resurrection Remix v5.8.1 Roms ???

Make sure to use supersu and not the inbuilt lineage superuser.

On rr it should run without an issue. At least it was reported in the xl thread.
20th February 2017, 11:35 AM |#11  
TheBurgh's Avatar
Senior Member
Flag Pittsburgh
Thanks Meter: 195
Currently rooted on 7.1.1 and haven't ventured away from stock. It should be good just to follow instructions and flash?
Post Reply Subscribe to Thread

kernel pixel smooth performance battery

Guest Quick Reply (no urls or BBcode)
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes