Hey guys and girls,
So straight to Topic.
The Kirisakura-Harmony is based on the latest google sources. On top of it are the latest EAS patches directly from Linaro. It also includes a few Audio Patches from CAF. Power Gating is disabled so you can use this kernel with @chdloc ´s excellent, I am wholeheartedly recommending it, biquads mod. If you grasp what you can do with it, you will never need an equalizer in your life again. So this is also an audio oriented kernel.
As I said I am still learning. The Feature list Comes here:
- Based on the latest Sources from Google for Android Q/10
- Upstreamed to 3.18.140
- Schedutil included again
- GPU Adrenoboost
- Wake gestures from flar2
- KCAL from savoca and ported by tbalden
- HBM enabled and accessible for the user
- Backlight dimmer is added
- FIOPS, SIO and MAPLE I/O Scheduler included
- Updated BFQ I/O Scheduler
- I managed to merge some Audio Patches from CAF, which should enhance Audio
- Power Gating disabled so you can use @chdloc ´s biquad mod
- Vibration Control
- Sound Control
- sdcardfs
- Sched and latest Schedutil (with latest upstream patches is also default)
- Updated EAS Machinery
- USB fast charge
Instructions for Android P
How to flash the Kernel:
1. Download the kernel.zip to your device
1a. Optional: While it may not be necessary all times, you may want to restore stock boot.img, re-root with magisk and optionally install twrp.zip if coming from another kernel. Before reporting issues make sure you do that! Thank you!
You only need to do either 2a OR 2b
2a. Boot to TWRP and flash my kernel.zip. Root will be preserved!
or
2b. Flash kernel zip in EX Kernel Manager or FKM app. Root will be preserved!
3. After booting up make sure to set schedutil as default CPU governor (check apply on reboot option) to fully profit from the kernel´s changes!
4. Enjoy your device now!
Android 10 Download:
Download:
https://www.androidfilehost.com/?w=files&flid=300707
Download for PIE
Download:
https://www.androidfilehost.com/?w=files&flid=198589
Oreo Kernel Stuff
Download:
https://www.androidfilehost.com/?w=files&flid=152851
Changelog-Mainline:
0.1
- Initial release
0.2
-added safetynet patch
0.3
- Add GPU OC
- Update wake gestures
- Many new Performance Patches
- Updated dm verity
0.4_1
- More performance tweaks
- Made my kernel a flashable zip <-- I hope you guys are satisfied now
0.5
- add Slimbus OC <-- Increases Audio Quality
- Various crypto Patches
- More Patches that may help with Performance
- added wakelock Patches
- added a few alsa patches
0.6
- added soundcontrol
- disabled some logging stuff
- some more tweaks
0.7
-enabled few other tcp congestion algorithms <-- westwood is now default
- set default iosched to deadline as it works best with eas kernels if we trust the documentation
0.8
- added sdcardfs <-- take a look at the FAQ on how to enable it
- added in two new governors, alucardsched and darknesssched
- merged in some other commits. take a look at my github
0.9
- when deactivating kernel side dt2w and s2w, one is still able to use the stock google dt2w implementation
- code updates for both alucardsched and darknesssched <--- if anyone has time please test and report back how they work with 0.9
- added option for GPU boost <--- disabled by default, take a look at the faq please
- update to cpuidle <--- deep sleep is improved for me
- the simple_ondemand GPU governor is now usable and does not crash upon choosing
- fix an issue were tasks were not given properly to cpusets
- a few other changes, please take a look at my github
0.9_5
- fixed a typo which would the user not choose msm-adreno-tz GPU governor after choosing simple_ondemand <--- also have no worries I implemented a patch that will let you choose only GPU governors that will not crash
- a few more commits for schedutil and sdcardfs
0.10
- all security patches
- some patches that may help with efficiency
- many patches to schedutil,sched, and walt (many)
- few patches to sdcardfs
- tuned WALT values a bit
- other things I forgot, check my github
0.11
- I added a few additional commits to adrenoboost, it is now more conservative and suited for daily use. I run it on moderate boost and don´t notice any battery drain
- performance of the fingerprint reader may be improved <-- I need feedback from you, don´t use it myself
- update to slimbus OC
- a few patches that may help with stability and performance in general
- many patches to schedutil , it is the recommended governor now in conjunction with nohint.zip
- introduced a new governor, called helix_schedutil based on schedutil; thanks to @ZeroInfinity
I had a little play with it, if anyone finds better values I can include them.
- for more details check my github
- please check this post prior to flashing: https://forum.xda-developers.com/showpost.php?p=71415045&postcount=210
Changelog for 0.12:
- added blu active governor
- updates to helix_schedutil, alucardsched and darknesssched
- updates to sdcardfs
- maybe some performance improvements <-- please give feedback
- other things look at my github
- made a non oc version
- please check this post prior to flashing: https://forum.xda-developers.com/showpost.php?p=71502126&postcount=241
Changelog for 0.13
- Implemented CPU_Input_Boost by sultanxda <--- disabled by default, if you experience scrolling lag activate it in EXKM, CPU Tab
- Implemented a new sched governor called energy-dcfc (Dynamic Capacity and Frequency Capping), more information in second and third post
- Some adjustements for schedutil
- Updated helix_schedutil
- some improvements to alucardsched and darknesssched
- adjusted WALT to final parameters
- bumped up and improved BFQ, thanks @DespairFactor <-- new default
- introduced Maple I/O scheduler
- updated sdcardfs
- please check this post prior to flashing: https://forum.xda-developers.com/showpost.php?p=71502126&postcount=241
Changelog for 0.14
- Added April Security Patches
- Updates to Schedutil, Sched, energy-dcfc
- Introduced a new EAS governor called pwrutil <-- more information on the second post
- Some upstream patches
- some more crypto patches
- updated wakelock blockers
- for other things look at my github
- please check this post prior to flashing: https://forum.xda-developers.com/showpost.php?p=71502126&postcount=241
Changelog for 0.16
- Linux Kernel Version is now 3.18.51
- Applied May security Patches
- many other little improvements and changes
Changelog-Rebase:
- Features EAS 1.2 Machinery
- May security update
- Linux version 3.18.53
- Includes all features from mainline except the EAS Governors (sched and schedutil are included) and CPU Boost.
- IO switcher
- some patches to schedutil
1.24
Updated sdcardfs
little performance tweak
updates to low power mode
1.28
- IO switcher
- some patches to schedutil
1.29
- performance tweak
1.32
- 3.18.55
- June Security Update
1.36
- updated sdcardfs
- EAS patch
- Linux Bump to 3.18.56
- ipv6, net and ext4 patches
1.40
- Linux Version now at 3.18.59
- July Security Patches
- updated sdcardfs
- little patch for sched
- boost now also ufs storage controller upon turning on the screen additionally to boost ddr bandwidth(even faster wakeup)
- extended recharge rate when battery is near full (aids longevity of our battery)
Changelog-Harmony:
4.00
https://forum.xda-developers.com/showpost.php?p=75835635&postcount=1105
5.01
https://forum.xda-developers.com/showpost.php?p=76106520&postcount=1129
6.00
https://forum.xda-developers.com/showpost.php?p=77515614&postcount=1166
6.01
https://forum.xda-developers.com/showpost.php?p=77533981&postcount=1178
6.02
https://forum.xda-developers.com/showpost.php?p=77588617&postcount=1180
6.04
https://forum.xda-developers.com/showpost.php?p=77758260&postcount=1188
6.05
https://forum.xda-developers.com/showpost.php?p=77776533&postcount=1189
6.06
https://forum.xda-developers.com/showpost.php?p=78125103&postcount=1198
6.07
https://forum.xda-developers.com/showpost.php?p=78342154&postcount=1209
7.00
https://forum.xda-developers.com/showpost.php?p=78916917&postcount=1243
7.01
https://forum.xda-developers.com/showpost.php?p=78968314&postcount=1251
8.10
https://forum.xda-developers.com/showpost.php?p=79506878&postcount=1287
10.0
https://forum.xda-developers.com/showpost.php?p=80581575&postcount=1301
10.1.0
https://forum.xda-developers.com/showpost.php?p=81119421&postcount=1311
FAQ:
Q: Which app do you recommend to apply changes to the kernel?
A: EX Kernel Manager from @flar2 is a great choice. He is constantly updating it.
Q: Which CPU governor I can choose freely and not hinder the EAS?
A: schedutil
Q: what is GPU boost and how should I choose the boost level?
A: I also implemented GPU Boost.
if you use the default GPU governor which is msm-adreno-tz you will have the option of GPU boost in EXKM. if you choose simple_ondemand not.
I think GPU Boost is not really needed on this phone as it raises GPU freqs aggressively enough for most tasks. So I leave it disabled at default.
It was originally introduced on the HTC 10, to counter an issue whereby the GPU failed to scale up aggressively enough, to run some not demanding games properly in 60fps locked. But there are some performance junkies (like me) who want to try such things.
So you can enable this setting and it has 3 profiles. Low, medium and high. It defines how aggressively the GPU gets scaled up.
I found GPU boost on low to be quite a good all day setting. Maybe a little bit more performance and not a too big hit on battery.
Medium and High are definitely more battery hungry and you should do this only for gaming or benchmarks.
Q: What is the difference of WALT and PELT and how does it affect me?
A: https://forum.xda-developers.com/showpost.php?p=71336204&postcount=179
Credits:
@Eliminater74 for bringing me into the game and the Inspiration
@flar2 for all his work
@tbalden
@savoca
@franciscofranco
@DespairFactor for the zip and the help
@Alucard24
@ZeroInfinity
@RenderBroken for helping me out
@dorimanx
@Sultanxda
if i forgot anyone just pm me and I will gladly add you
Source: https://github.com/freak07
Info Post
So this post will be dedicated to information about EAS in general.
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):
Code:
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:
Code:
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:
Code:
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
FREQ_RESPONSIVENESS
PUMP_INC_STEP_AT_MIN_FREQ
PUMP_DEC_STEP_AT_MIN_FREQ
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
Tldr;
Schedutil: simpler
Alucardsched: more tunable
Code:
IF CURRENT_FREQ < FREQ_RESPONSIVENESS:
PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ are used
ELSE:
PUMP_INC_STEP and PUMP_DEC_STEP are used
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
Explanation:
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 NOT MEANT TO BE USED WITH SCHEDTUNE.BOOST AT THE SAME TIME! EITHER USE ONE OR THE OTHER OR ELSE PERFORMANCE WILL BE OVERKILL AND BATTERY LIFE WILL DRAIN MUCH FASTER!!!
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.
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
4
ramopps:Some Documentation on Ramopps
Normal Logcat:
Radio Logcat:
Ramoops:
Via adb:
adb shell su -c cat /sys/fs/pstore/console-ramoops > kmsg.txt
Via terminal on phone:
su
cat /sys/fs/pstore/console-ramoops > /sdcard/kmsg.txt
Kernel Log:
Kernel Log:
adb shell su -c dmesg > dmesg.log
Last_Kmsg:NOTE:
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
NOTES:
-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
URL: http://forum.xda-developers.com/showthread.php?t=2185929
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..
Excellent work my friend thanks for supporting the Pixel XL I hope you get lots of joy from your new hobby!
Will flash in the morning and see how it goes...
Most of those audio patches you backported seem to be interesting, specially the ones that are meant to reduce power comsumption. Will pick. Suggestion, you don't need to specify the slot in the fastboot command, just fastboot flash kernel kernel_binary
can you disable storage force-encryption？thanks！
Sent from my Pixel XL using XDA Labs
Are the safetynet patches implemented by any chance?
franciscofranco said:
Most of those audio patches you backported seem to be interesting, specially the ones that are meant to reduce power comsumption. Will pick. Suggestion, you don't need to specify the slot in the fastboot command, just fastboot flash kernel kernel_binary
Click to expand...
Click to collapse
When I did only fastboot flash, I ended up twice with a system that somehow didn’t know which boot slot to boot to.
Each reboot it would boot into the different boot slot. The only thing that resolved this was to flash the factory image from google.
Even specifying the boot slot via fastboot did not alter this behaviour.
Somewhere in the q & a section someone is describing the problem too. It occured the first time after using fastboot flash kernel command.
almightysiman said:
can you disable storage force-encryption？thanks！
Click to expand...
Click to collapse
I will look into it.
ghostENVY said:
Are the safetynet patches implemented by any chance?
Click to expand...
Click to collapse
No I didn’t implement them yet. I will look into it.
Let us know when you'll have a flashable zip for this! Sounds good!
Thanks for another kernel option!
Sent from my Pixel XL using XDA Labs
Freak07 said:
When I did only fastboot flash, I ended up twice with a system that somehow didn’t know which boot slot to boot to.
Each reboot it would boot into the different boot slot. The only thing that resolved this was to flash the factory image from google.
Even specifying the boot slot via fastboot did not alter this behaviour.
Somewhere in the q & a section someone is describing the problem too. It occured the first time after using fastboot flash kernel command.
Click to expand...
Click to collapse
Well, I've been using that command since day 1. I've flashed countless times, it never failed to boot once...
franciscofranco said:
Well, I've been using that command since day 1. I've flashed countless times, it never failed to boot once...
Click to expand...
Click to collapse
are you running stock rom? I believe you, if you say, you never had issues.
I ran into the issue I described earlier. It would Change Slots upon each reboot and nothing except flashing back stock Google Image fixes it.
new kernel 0.2 is available
I added safetynet patch and another commit that may help with Performance
Download is here or in the OP
https://www.androidfilehost.com/?fid=529152257862702410
It's great to see development for our beloved Pixel XL! I'll be checking this out. I thank you friend!
Freak07 said:
It also includes a few Audio Patches from CAF.
Click to expand...
Click to collapse
Anything related to aptX Bluetooth?
CZ Eddie said:
Anything related to aptX Bluetooth?
Click to expand...
Click to collapse
Don’t know. What are you searching for exactly?
Hey
I updated the kernel to 0.3
Main changes are:
- Add GPU OC to 652mhz like the performance edition of our soc
- Update wake gestures
- Many new Performance Patches
- Updated dm verity
Download is here:
https://www.androidfilehost.com/?fid=745425885120707916
Lots of sweet features and commits. Definitely keeping my eye on this kernel. :good:
Can you make it TWRP flashable please?
Sent from my Pixel XL using XDA Labs
Related
Diet Android Kernel 2.6.33.2 by PsyQ
I am releasing the kernel which I use by myself I removed most of the debugging options useful for kernel/driver debugging and maxed-out possible compiler optimizations. It has Hybrid AVS support using IntersectRaven's improved method as well as optional overclocking (see note)
These kernels feature:
* Hybrid Adaptive Voltage Scaling for extra battery life
* Optional 1.1 GHz Overclocking Support
* Extra 8 MB of RAM reclaimed from Camera
* Based on Cyanogen's 5.0.6 kernel
* Maximum possible compiler optimizations (loop unrolling, tree vectorization, NEON, Cortex A8 compiler tuning, armv7a target, and many more)
* Removed all unnecessary features from the kernel configuration, including debugging options (these kernels are not useful for kernel debugging / driver development)
* All cpufreq governors (ondemand, powersave, conservative, ...) for people that want to tweak the CPU frequency scaling
Following kernels are available:
diet_2.6.33.3.hybrid_avs_800mv.zip --> Hybrid AVS support, goes down to 0.8 volts and has stock frequency (998 MHz) as max.
diet_2.6.33.3.hybrid_avs_800mv_OC.zip--> EXPERIMENTAL Hybrid AVS with overclocking to 1.1 GHz (0.8v min voltage)
diet_2.6.33.3.hybrid_avs_925mv.zip --> Hybrid AVS support, goes down to 0.925 volts and has stock frequency (998 MHz) as max.
diet_2.6.33.3.hybrid_avs_925mv_OC.zip--> EXPERIMENTAL Hybrid AVS with overclocking to 1.1 GHz. (0.925v min voltage)
To use it, flash the zimage with fastboot and push the bcm4329.ko to the /system/lib/modules:
Code:
[power off your phone and boot into fastboot]
fastboot flash zimage zImage
[reboot]
adb remount
adb push bcm4329.ko /system/lib/modules/bcm4329.ko
Pushing of the bcm4329.ko is necessary as WiFi support would be broken otherwise. If you don't do it, WiFi will not work.
Changelog:
Code:
V1.11 - Update - May/02nd/2010
- Moved to 2.6.33.3 Kernel
V1.10 - Update - Apr/26th/2010
- Changed floating point model to VFP
- There are two AVS versions with different lowest voltage limits (800/925mv)
V1.09 - Update
- Implemented IntersectRaven's Hybrid AVS method
- Synced with the latest code snapshot of CM kernel
V1.08 - Update
- Non AVS kernel is now undervolted down to 0.925v
- Kernel RCU is now of uniprocessor type, saving memory
- DMA speedup patch from latest CM source
- Removed "loopback" file device (this is not related to network)
- Further compiler optimizations
V1.07 - Update
- 8 MB RAM reclaimed from Camera
- Further kernel trimming
- AVS is now available with 0.925v and 0.850v flavors
- Some attempts to make AVS more stable (still work in progress)
V1.06 - Update
- Moved to kernel 2.6.33.2 from Cyanogen's 5.0.5.6 source
- AVS kernels are capable of undervolting down to 0.925v instead of 1.000v
- Minor cleanups
V1.05 - Update
- Further fixes in AVS Support (thx intersectRaven!)
V1.04 - Update
- Fixed bugs in AVS Support
- More kernel tweaks
- Removed "normal" version of the kernel, as _xtra seems to be stable enough
- Added non-overclocked AVS kernel for maximum battery life
V1.03 - Update
- Added Experimental Adaptive Voltage Support (AVS)
- Currently AVS is "for test only", and this kernel has debug support and no loop unrolling
V1.02 - Update
- Switched to CFQ I/O Scheduler
- Removed some more stuff (e.g. 10 Gbit Ethernet Support)
V1.01 - Update
- Added Conservative Governor
- Fixed table lookup bug (thanks pershoot!)
V1.0 - Initial Release
- Based on CyanogenMod 5.0.5.3 source
- Overclocking Support (1.1 GHz)
- Undervolted
- Optional extra undervolt (see attachments - _xtra is additional UV)
- Added Powersave CPU governor
- Removed most of the debugging stuff from Kernel (which makes this kernel useless for kernel debugging!)
- Even more C compiler optimizations (almost -O3 level + extra stuff, like loop unrolling, etc...)
- Audioboost patch
For other kernel developers - you can find the source code here (note that for AVS support you need AVS sources from ChromeOS):
http://github.com/psyq321/nexus_one_kernel_additions
Do you use the xtra version, if so have you noticed any problems
Nice release, will definitely try sometime.
Grrr!!! checked for updated version right before leaving for work, and just missed it!
I am using the one you posted in the other forum without any issues. Does it possess the same undervolting as the Xtra version?
Yes, _xtra is using same undervolt as the version from yesterday.
Additionally, this version contains more optimizations (loop unrolling) that I managed to cram-in by removing more debug options of the kernel (otherwise it would not fit)
What is loop unrolling?
Awesome, I'll pull the config to see what you have done...
just installed on my device. so far so good, using the extra undervolt. booted fine and everything so will report back later if I notice anything weird.
Hi man, in first thanks for this work...
Now can u tell me how can i use your kernel?
Thanks in advanced
just
[power off your phone and boot into fastboot]
fastboot flash zimage zImage
[reboot]
adb remount
adb push bcm4329.ko system/lib/modules/bcm4329.ko
interesting...I've been experimenting with the compiler optimizations in my own build...it made the kernel bigger although I feel a bit more responsiveness now...almost not noticeable but I think its there...
xPatriicK said:
What is loop unrolling?
Click to expand...
Click to collapse
Loop unrolling is the optimization technique used by modern compilers to potentially speed-up execution by decreasing overhead of the loop passes.
For example, imagine that you have a loop, that does something 4 times:
Code:
for(x=0; x<4; x++) {
do_something;
}
In this case, some % of the execution will be checking if the x is less than 4, and if no - "doing_something" again. This check has to be performed for every step (so, it is done 4 times)
Now, if you unroll this loop, it would look like this:
Code:
do_something; x++;
do_something; x++;
do_something; x++;
do_something; x++;
^ So, in this case, we completely eliminated checks.
Or, if the loop is much bigger (say, x goes up to 800):
Code:
for(x=0; x<800; x+=4) {
do_something;
do_something[x+1];
do_something[x+2];
do_something[x+3];
}
See? In this case, you reduce the number of condition checks for bigger loops.
This can sometimes make code faster - but the downside is that it makes the code bigger (which is obvious even in those examples above).
In Android Kernel 2.6.33.1 case - loop unrolling increases zImage size by ~350K. If I didn't strip debugging stuff out, zImage would be too big to fit on Nexus One.
Fortunately, there was approx. 400K to be saved by just kicking out features that enable kernel debugging. I don't think most of the people need that. These features are useful for kernel and driver developers, but most of others can perfectly live without them
Alright, thank you!
will try _xtra when Paul released the new Desire cam. Thanks for your work
Ivan Dimkovic said:
Loop unrolling is the optimization technique used by modern compilers to potentially speed-up execution by decreasing overhead of the loop passes.
For example, imagine that you have a loop, that does something 4 times:
Code:
for(x=0; x<4; x++) {
do_something;
}
In this case, some % of the execution will be checking if the x is less than 4, and if no - "doing_something" again. This check has to be performed for every step (so, it is done 4 times)
Now, if you unroll this loop, it would look like this:
Code:
do_something; x++;
do_something; x++;
do_something; x++;
do_something; x++;
^ So, in this case, we completely eliminated checks.
Or, if the loop is much bigger (say, x goes up to 800):
Code:
for(x=0; x<800; x+=4) {
do_something;
do_something[x+1];
do_something[x+2];
do_something[x+3];
}
See? In this case, you reduce the number of condition checks for bigger loops.
This can sometimes make code faster - but the downside is that it makes the code bigger (which is obvious even in those examples above).
In Android Kernel 2.6.33.1 case - loop unrolling increases zImage size by ~350K. If I didn't strip debugging stuff out, zImage would be too big to fit on Nexus One.
Fortunately, there was approx. 400K to be saved by just kicking out features that enable kernel debugging. I don't think most of the people need that. These features are useful for kernel and driver developers, but most of others can perfectly live without them
Click to expand...
Click to collapse
on point. i like what i see. i will try this out.
If I use the powersave governor option, SetCPU always show it running at minimum 245MHz. Is it working as expected?
bethedealer said:
If I use the powersave governor option, SetCPU always show it running at minimum 245MHz. Is it working as expected?
Click to expand...
Click to collapse
That's fine since the powersave governor clocks it to the lowest for maximum power savings.
standby 245/245 governor is better than on demand?
xPatriicK said:
standby 245/245 governor is better than on demand?
Click to expand...
Click to collapse
Curious about this too!
xPatriicK said:
standby 245/245 governor is better than on demand?
Click to expand...
Click to collapse
It's not necessarily better. It depends on what you're optimizing for. For example, powersave governor optimizes for power savings in return for slowest clock speed which may be apparent when using CPU intensive apps. Ondemand tries to balance it somewhat while giving more importance to CPU speed since it clocks the CPU back to full speed whenever an app runs and downclocking when appropriate. The conservative governor I use in my kernel also tries to balance this but gives more importance to power savings since when an app runs it slowly ramps up the clock speed until the app finishes. Hope this clears it up!
Note that powersave might actually consume more power at the end if you do some intensive work.
Why? Because it will force CPU to stay at the lower clock, even if the task could be completet much quicker with the higher clock.
At the end - it could very well be that running the task quicker @higher clock speed could consume less power total!
Unfortunately, there is no easy way to test what is better, unless someone writes a script that performs some tasks repeatedly until battery dies, and compares the baterry life between different CPU scaling strategies.
I'd definitely not use powersave governor. Rather, I'd play with the "up threshold" and "profiles" in SetCPU to make the CPU frequency scaling more conservative.
motley kernel for the Nexus 7 and Jellybean
Disclaimer: You know the gig...I am not responsible for damaging your device or voiding your warranty. Play at your own risk!
ROM devs/cooks: If you want to use this kernel in your ROM, I am fine with that, but please include a "thanks" and a link back to this thread. Thanks!
Requirements (please read carefully and visit the other dev threads as necessary)
You must be unlocked and rooted.
You must have custom recovery installed (CWM or TWRP) to install the kernel.
Busybox is required for init.d support.
Do a backup using custom recovery (CWM or TWR) so you can restore your boot.img and ROM if necessary!
Have your ROM zip in /sdcard so you can restore your ROM if necessary.
System Tuner is recommended for tuning the CPU, especially for voltage control.
Main Features
GPL compliant - source is kept up to date at github.com and released at the time the kernel is released to the public for all builds. Ask other devs to do the same!
Asus\Nvidia\Google Linux 3.1.10 base. All stock features are supported (camera, OTG, NFC etc.)
OC to 1.6GHz (optional)
Voltage control - be careful to not save the setting on boot until you are 100% sure!
GPU OC from 416 to 520MHz (default is 446, adjust as you wish up to 520MHz)
Dynamic EDP - allows EDP to remain enabled (safer), but with an added simple temperature throttle switch (based on Asus Prime)
Compiler optimizations (-O2) - using Linaro 4.7 ARM toolchain
I/O schedulers - row (default), SIO, V(R), CFQ, NOOP, and deadline
TCP Congestion Control - default cubic + several different algos to choose from.
ZRAM - must be enabled by a script
Governors - Interactive (default), Performance, OnDemand, PowerSave, Conservative
initramfs - insecure (your ROM must have busybox)
CIFS/UTF8, NFS, NTFS r/w, TUN - built-in, no need for any kernel modules
fsync sysfs enable/disable switch (defaults to fsync enabled)
kexec with hardboot (for supporting Linux/MultiROM)
Many other misc patches and tweaks (see github link below)
Install:
Check the requirements above!
Flash the zip using custom recovery (no need to wipe anything)
See post 2 for performance tweaks and more info
build #249 for Jellybean 4.2.2 - WiFi and 3G 2013-02-24
Added ability to change GPU clock speed at runtime (referenced franco, morific, and metallice git repos)
Added row io scheduler and set as default (Tatyana Brokhman)
Added TCP Congestion Control, several different algos to choose from. Default is cubic (stock).
Added optimized ARM RWSEM (Ezekeel)
Input patch (Henrik Rydberg)
View attachment motley_anykernel_N7_build_249.zip
build #247 for Jellybean 4.2.2 - WiFi and 3G 2013-02-17
Merged 4.2.2 patches
Updated Linaro toolchain to 2012.12
View attachment motley_422_nexus7_anykernel_build_247_446GPU.zip
build #246 for Jellybean 4.2.1 - WiFi and 3G
kexec\MultiROM support
Download from here since I posted in the MultiROM thread
build #244 for Jellybean 4.2 - WiFi and 3G - Recommended for WiFi and 3G on 4.2.x
446 GPU build (stock + 30MHz). Let's see if this fixes touchscreen issues for those having them. My theory is that after the GPU heats up, this starts to affect touchscreen behavior on some devices. This is likely what happened to me on build 234 when I was testing. The GPU definitely gets hot on this device even with normal usage at 484+. At 446 this doesn't happen. IMHO, we are reducing the life of the device by overheating the GPU repeatedly. My Antutu scores actually tested higher after I flashed the 446 build.
Supports Android Jellybean 4.2.x
Reverted some commits from 233
Removed KSM from config, no ROM is using this AFAIK
Panel clock reduced to match Nvida cardhu sources (74180000). Having the panel clock cranked up fakes out scores on some benchmark tests, but adds no real value.
View attachment motley_nexus7_anykernel_build_244_446GPU.zip
Previous builds and release notes
build #234 for Jellybean 4.2 - First properly working 3G build
Supports Android Jellybean 4.2.x
Only change - added CONFIG_USB_NET_RAW_IP=y to hopefully address any issues with 3G (reported working by DiamondBack)
View attachment motley_nexus7_anykernel_build_234_484GPU.zip
build #233 for Jellybean 4.2 - if you don't have issues with GPU OC @484, this build may work well for you.
Supports Android Jellybean 4.2.x
Updated to latest Linaro toolchain 2012.10.22 and tweaked some compiler options.
Should support 3G as I have merged the Google patches, but I have not tested this.
Removed WiFi PM_FAST toggle as I see no need for this (PM_MAX for better battery is already the default in stock)
Stopped logging temp warnings until lit gets to 65C near the EDP throttle limit.
Quad-core tweaks - referenced showp1984's bricked grouper kernel source
See github for other minor details.
View attachment motley_nexus7_anykernel_build_233_484GPU.zip
build #232 - Recommended for WiFi on 4.1.2
Added support for Android Jellybean 4.1.2
Updated to latest Linaro toolchain 2012.10.22.
View attachment motley_nexus7_anykernel_build_232_484GPU.zip (GPU OC 484MHz)
stable v1.1.1 - builds #218-220 - Recommended for WiFi on 4.1.0 or 4.1.1
Supports Android Jellybean 4.1.1 or 4.1.0
DVFS tweaks and drop top cpu frequency to 1600, not much is lost and it should now be stable for everyone I hope. We pushed the envelope to 1.7 and 1.624 and now we are back to real world sensible decisions. My Nenamark2 520 GPU scores actually went up.
Dynamic EDP temp adjusted from 67 to 68C to catch temp notifier quicker when cooling back down.
Other miscellaneous patches
Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)
View attachment motley_anykernel_nexus7_1.1.1_NoGPUOC_build_220.zip (GPU stock 416GHz)
View attachment motley_anykernel_nexus7_1.1.1_GPU484_build_219.zip (GPU OC 484MHz)
View attachment motley_anykernel_nexus7_1.1.1_GPU520_build_218.zip (GPU OC 520MHz)
alpha v1.1.0 - builds #213-215
Added fsync sysfs enable/disable switch (thanks Ezekeel). fsync is still enabled by default. For more info and how to disable, see post 2.
Experimental: now forging speedo id 4 and process id 2 so that EDP limits are slightly raised and it narrows everyone down to a common DVFS record for everyone. Raised Dynanic EDP governor to 67C (from 60C) to give a little more room before edp is allowed to enable.
Minor cpu voltage table tweaks aiming for slightly better battery for those that don't undervolt.
Lowered the cold offsets from 50 to 25 for the top 4 cpu voltage slots. This will give folks a little more breathing room when undervolting and may help cold performance a bit if your voltages are lowered close to their lower limit.
Deadline i/o scheduler (morfic's secret 1:1 sauce that I remember back from my Iconia A500 days!). SIO is still the default, but we can try it out and see what we think.
OnDemand really wasn't usable in it's stock state since it was so laggy, so I have made some tweaks to the tuneables and it seems to be better now for those that want to give it a spin. Interactive is still the default governor.
cpu transtition latency lowered - fairly certain that it only affects OnDemand governor and not Interactive (reference morfic and http://permalink.gmane.org/gmane.linux.ports.tegra/1649)
Reverted most of the adjustments to the tegra 3 algorirthim for bringing cpus online and offline. I think it livened it up, but at the expense of battery.
Added kernel config option BCMDHD_WIFI_PM (thanks Ezekeel). See post 2 on how to enable it (not recommended unless you have music steaming issues when the screen is off). Not yet tested.
Other miscellaneous tweaks
Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)
View attachment motley_anykernel_nexus7_1.1.0_NoGPUOC_build_214.zip (GPU stock 416GHz)
View attachment motley_anykernel_nexus7_1.1.0_GPU484_build_213.zip (GPU OC 484MHz)
View attachment motley_anykernel_nexus7_1.1.0_GPU520_build_215.zip (GPU OC 520MHz)
stable v1.0.12 - builds #175-177
Changed highest frequency back to 1.624GHz and core voltage back to 1200mV. After experimenting with higher core voltages and 1.7GHz probing our limitations, it just doesn't seem right on this tablet. Why fry the butter?
CPU voltage is capped at 1237, so don't set it higher than that if tuning.
Refresh rate now adjusted with GPU OC clock at compile time. Higher FPS should be realized at 484 and 520 for most (thanks to clemsyn for sharing his research and findings)
Adjustments to the tegra 3 algorirthim for bring cpus online and offline, especially for the OC frequencies.
Fixed GPU clock compile time switch. Removed 500MHz choice.
Set cpu frequency policy to 1.3GHz on startup. This should help with heat build-up on startup and users where the highest OC clock rate is not desired.
Lowest brightness setting set back to stock since several users were requesting it (18 back to 13).
Minor adjustment to the interactive governor to make it slightly more responsive when demands increase.
PowerHAL change so it doesn't mess with a couple other interactive governor tunables on init.
All frequencies throughout the power range should be used in a more balanced manner.
Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)
View attachment motley_anykernel_nexus7_1.0.12_NoGPUOC_build_177.zip (GPU stock 416GHz)
View attachment motley_anykernel_nexus7_1.0.12_GPU484_build_176.zip (GPU OC 484MHz)
View attachment motley_anykernel_nexus7_1.0.12_GPU520_build_175.zip (GPU OC 520MHz)
alpha v1.0.11 - builds #126-128
Changed highest frequency from 1.624 to 1.7GHz
Increased core voltage for the highest frequency to 1250mV. This should bring some increased stability at the highest two overclock frequencies (thanks to clemsyn and Pinoyto for their help)
Tweaked DVFS table for the GPU. It should now scale a bit better and still bring the same performance and the top end.
Lowest brightness setting increased from 13 to 18 (thanks to clemsyn). Lets give this a try and we can increase it further if need be. The brightness levels can be tweaked on the ROM side as well in the N7 device tree, at least when you build from scratch, so we don't want to be too limiting here.
PowerHAL fix now included /vendor/lib/how/power.grouper.so (thanks to imoseyon). See this post to see the code I changed.
(Removed download links since many were reporting random reboots. I think v1.0.12 is better anyhow)
stable v1.0.10 - build #110/111
CPU frequecies back to 1400, 1500, 1600, and 1624 (leaving the new highest setting)
DVFS table tweaks
Frequency table fix fix for 1624 (thanks to Clemsyn for bringing to my attention!)
Only stock and 484MHz GPU OC version - code switch is still there for those that want to compile and experiment. Moving beyond 484 doesn't show any benefit. My best Nenamark2 score 62.7 was achieved on 484MHz.
Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)
experimental v1.0.9 - builds #102-105
CPU OC to 1.624GHz - higher end CPU frequencies are now at 1408, 1504, 1600, and 1624 (old 1400, 1500, 1600, N/A)
DVFS table tweaks - Just in case, please note and then unset your saved voltage control settings before using the new version.
GPU versions stock, 484, 500 and 520MHz builds for testing
Added a GPU OC kernel config choice switch to allow compile time selection of GPU speed (446, 484, 500, or 520MHz).
NTFS r/w enabled
PegasusQ governor no longer built in, but code remains if we want to look further into when time allows.
Reduce some temp reporting kernel log spam until the temp gets a little higher
stable v1.0.8 - build #77/78
Added PegasusQ governor - experimental only, not enabled by default (thanks Samsung SGSIII source and gokhanmoral for tweaks)
Revert "HACK: block fbearlysuspend to not break androids crt-off animation"
Added LulzActive governor, but not built-in due to issues.
stable v1.0.7 - build #70/71
Voltage Control tweak - let's ignore the highest freq slot for show and
save since it shows 1.6GHz twice in the voltage table in System Tuner.
We are are only allowing 1200mV for 1.6, so the top slot is not
currently used. See my notes in post 2 about voltage control.
cpu-tegra: let's skip the temporary downclock and kernel log spam if the
custom Dynamic EDP throttle is not currently enabled.
ARM/VFP compiler optimization
compilation: fix annoying and serious warnings (thanks faux123!)
video: tegra: host: Fix error case memory leaks
When a submit fails, the related nvhost_job is not freed. Add an
explicit free. Also, 3D is mapping the save buffer, but it is not
unmapped (Nvidia)
mm: Ensure pte and pmd stores ordering (Nvidia)
Get rid of some more kernel log spam.
HACK: block fbearlysuspend to not break androids crt-off animation
(thanks codeworx, drewis (repo) and aaronpoweruser for pointing it out). This is untested (by me), but this may help with ROMs that
have this functionality (AOKP etc.)
cpu-tegra3: modified the hot-plug governor down_delay to be 1s
instead of 2s
stable v1.0.6 - build #47/48
GPU clock increased to 484MHz - Nenamark2 scores of 61+
More compiler optimizations (-fmodulo-sched, -fmodulo-sched-allow-regmoves, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize, -floop-interchange, -floop-strip-mine, -floop-block, -mfpu=neon )
Now using Koush's AnyKernel delivery method. Uses your existing ramdisk so you can easily use with any ROM.
stable v1.0.5 - build #39
Honor your max frequency fix - no more spikes
alpha v1.0.4 - build #38
Fixes units that can't OC (process_id = 3)
Linaro 4.7.1 toolchain -O2 (2012-06-25)
Increased panel clock rate - increases fps without further GPU clock Nenamark2 scores 59.6 best score so far for Nexus 7
ramdisk added back in boot 1.3GHz, but device still spikes to max allowed CPU freq sometimes (see update below, will be fixed in 1.0.5)
Minor clock and voltage adjustments - should run a bit cooler and use less battery.
Added GPU OC compile switch in case we want a non-OC GPU build.
Added some VPN/networking capabilities for those that need it (L2TP, IP_GRE_DEMUX,INET_AH, INET_XFRM_MODE_BEET)
Some unnecessary debugging options turned off. Should save kernel RAM usage.
Some say it made wifi signal stronger again for them, but I never had any issues. Might be the toolchain and its effect on the broadcom driver. Reports that it is better are fine with me!
alpha v1.0.3 - build #17
UV support, minor voltage adjustments
V(R) i/o scheduler added
ramdisk removed custom init.rc line...hope this will fix the stock units that weren't booting!
alpha v1.0.2 - build #6
Mild GPU OC from 416 to 446MHz - baby steps...its been rock solid so far. NenaMark 2 scores are up from 55 to 57.2fps. A future release may have two versions, one with GPU OC and one without.
Upgraded toolchain to GCC v4.6.3 optimized google version by ezterry, see http://forum.xda-developers.com/showthread.php?t=1686310)
alpha v1.0.1 - build #4
Limit frequency to 1.3GHz on boot. It can then be OC'ed from there. This should make it safer for those that can't OC or don't want to.
Changes to allow OC for Process ID's 0 and 1. Theoretically, these should be earlier release versions like IO and earlier.
alpha v1.0.0 - build #1
This initial alpha release is working well on a Nexus 7 16GB (Speedo ID 7/Process ID 2) on JB 4.1.1. There are no open issues that I know about. Looking for some advanced users and testers to give some feedback, and then we can hopefully make it even better!
Thanks to:
fordwolden - for his generous donation of a Nexus 7
Google and Asus for releasing a nice, open, and inexpensive tablet for the masses.
drewis (Andrew Sutherland) - for the base kernel on github
paulobrien - thanks for the CWM touch recovery
birdman and FadedLite for their Unlock\Rooting instructions
clemsyn for his ideas and insight
Git repo:
https://github.com/motley-git/Kernel-Nexus7
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
(http://www.gnu.org/copyleft/gpl.html)
More info
last_kmsg
Please provide the dmesg output or last_kmsg if you experience any issues (random reboot or crashes) that you think are attributed to the kernel. I ask that you please test with the default/stock kernel first for your rom before you blame the issues on this kernel. Wait for the tab to reboot, or if it doesn't wait long enough so you can capture a good log. If you place this on your /sdcard, it will be easy to capture. Boot into recovery, flash this zip, and then flash a known kernel that works. Then reboot, and go grab the last_kmsg in /sdcard.
View attachment LastKMESG.zip (thanks go to CekMTL, I always keep this handy since you gave it to me!)
Voltage Control
What is voltage control?
It is simply allowing for the cpu voltage to be changed on the fly for each frequency step. CPU voltage is typically lowered (undervolting) for certain frequency steps to conserve power. For an overclocked device, some devices need more juice to be stable than others. Voltage control allows others not to pay this penalty and they can lower the voltage as they see fit for their device and usage needs.
Is undervolting safe?
If the lowered voltage values you enter are stable for the tablet, then absolutely it is safe.
What are the benefits?
Better battery life and less heat
Additional Info on voltage control
Only System Tuner is displaying the DVFS table frequency labels correctly and I recommend that you use this if you want to play with voltage control. SetCPU is showing the scaling frequencies when it displays them in the UI, some of which are for the LP core. This is not correct and is misleading, so it is best not to use it for this kernel.
Since the tools available only allow for tweaking one DVFS table (the high powered G cores), voltage control is not currently possible for the LP core. It is not needed anyhow IMO and setting it too low could result in SOD. There is more battery saving to be had with the G cores anyhow if you are into this sort of tweaking.
The frequencies shown may have two values for one frequency. This is how it came with the factory kernel as well and I have only tweaked the top end of the DVFS table. It may seem weird, but this gives us direct access to the DVFS table. I would recommend keeping it as a staircase, just like Nvidia has it even though some frequencies are listed twice.
The freqs shown in the System Tuner display will match the DVFS table for the cpu_process_id for your tablet (seen in the kernel log at startup). All tablets won't display the same frequencies. There are at least two maybe three or four variants we have found so far for the Nexus 7 with Tegra 3 SoC #7.
Also, some may not know, but the tegra3 kernel also has automatic UV using a "cold" zone in where 50mV undervolting is done automatically when the cpu is cool. Take this into consideration when playing around.
GPU OC
Valid max GPU frequency is 416 - 520 MHz. If you try higher or lower clock speeds, it will fail and remain unchanged.
Examples:
Code:
echo 484 > /sys/devices/system/cpu/cpu0/cpufreq/gpu_oc
Code:
echo 520 > /sys/devices/system/cpu/cpu0/cpufreq/gpu_oc
Performance Tweaks
These are a couple of tweaks that many are using for faster benchmarks and better battery performance. Google it and decide for yourself if you like the risk or not. I recommend that you do a full backup in recovery and regularly backup your /data partion or cloud sync if you enable these options. Will many run them daily as I now do, there is some additional risk. These can be added to scripts and automated via init.d or other apps/tools that support them.
To disable fsync for better battery and better disk i/o performance:
Code:
echo 0 > /sys/class/misc/fsynccontrol/fsync_enabled
To enable fsync for better data integrity (default)
Code:
echo 1 > /sys/class/misc/fsynccontrol/fsync_enabled
Faster disk i/o - remount /data partition with noauto_da_alloc option (google it, better battery, less data integrity)
Code:
mount -o remount,noauto_da_alloc /data /data
TCP Congestion Control Algorithms
Only one can be set at a time, so only add one of the lines to your script. Here are some examples:
Code:
echo "reno" > /proc/sys/net/ipv4/tcp_congestion_control
echo "veno" > /proc/sys/net/ipv4/tcp_congestion_control
echo "vegas" > /proc/sys/net/ipv4/tcp_congestion_control
echo "westwood" > /proc/sys/net/ipv4/tcp_congestion_control
zRAM
What is zRAM?
This is a mainline kernel feature for Compressed RAM block device support (CONFIG_ZRAM)
http://en.wikipedia.org/wiki/ZRam
Like many of the other tweaks done in the Android world, ZRAM is another one of them that is controversial, probably because people only think in terms of immediate performance they can measure easily with benchmarks etc. *Here is my take...think I will add this to the Q&A section as well.
But, will it make my device faster? Will I score higher on benchmarks?
It depends, but for normal usage, the answer is no. zRAM is most useful for those that are configuring Android to be a true multitasking workhorse. For example, if I enable zRAM, open an bunch of apps at one time, and actually start to work towards depleting the memory of the system. *For example, say I open system tuner, a browser with several tabs, a word processing app, a game, and perhaps a picture viewing app or a movie. If I don't formally close out of each one by hitting back and just begin switching between apps and the home screen, you will see zRAM start showing benefits.*
If you tweak the Android memory and swappiness settings, this can also be useful in this type of environment.
How do I know it is initialized and working?
You can type "free" from an command line and see the swap space.
Also, you can look at the disksize to see if it is initialized
cat /sys/block/zram0/disksize
To see how much it is being used in your environment, you can look at the output from:
cat /sys/block/zram0/num_writes
cat /sys/block/zram0/num_reads
So, unless you have a heavy workload as stated above, then it won't be of a lot of use for normal Android users.
How do I enable zram?
It must be enabled by a script. Some ROMs may support activating it. If you need to do it yourself you have two choices.
1) Save this to a file and run the script from terminal, Script Manager or System Tuner.
2) Or better yet, save this to a file called 90zram (or whatever you prefer) in /system/etc/init.d and automate it (The ROM's ramdisk needs to supports init.d)
Code:
#!/system/bin/sh
# auto zram activation init script with busybox search
# by show-p1984
echo "[90ZRAM]: Firing up /system/etc/init.d/90zram";
if [ ! -e /sys/block/zram0/disksize ] ; then
echo "[90ZRAM]: ERROR unable to find /sys/block/zram0/disksize";
echo "[90ZRAM]: Is this a ZRAM kernel?";
echo "[90ZRAM]: ZRAM NOT ACTIVATED. (404)";
else
#find busybox in /system
bblocation=$(find /system/ -name 'busybox')
if [ -n "$bblocation" ] && [ -e "$bblocation" ] ; then
echo "[90ZRAM]: busybox found in:" $bblocation;
echo "[90ZRAM]: Setting ZRAM disksize.";
echo $((100*1024*1024)) > /sys/block/zram0/disksize
echo "[90ZRAM]: Starting ZRAM...";
bblocation=${bblocation%/*}
cd $bblocation
./busybox mkswap /dev/block/zram0
./busybox swapon /dev/block/zram0
echo "[90ZRAM]: ZRAM activated.";
else
echo "[90ZRAM]: ERROR! busybox not found!";
echo "[90ZRAM]: Is busybox installed? Symlinks set?";
echo "[90ZRAM]: ZRAM NOT ACTIVATED. (404)";
fi
fi
Flashed with CWR and it doesn't boot past the Google screen Is there something special I need to do?
*Edit*
I am on the new 4.1.1 "D" or whatever but right now I'm using the Atlantis "1.5" kernel and it works so I donno.
Thanks for another addition to the nexus 7 kernel community, love having different kernels to try.
Clienterror said:
Flashed with CWR and it doesn't boot past the Google screen Is there something special I need to do?
*Edit*
I am on the new 4.1.1 "D" or whatever but right now I'm using the Atlantis "1.5" kernel and it works so I donno.
Click to expand...
Click to collapse
Thx, please grab the dmesg output while booting or last_kmsg if you can. Working fine here, but this why I put it out as an alpha. Even if you boot off another kernel, if you can send a dmesg captured right after boot, that would help so I can see your SoC/Process ID numbers. There are two lines written just after boot with the info. On the Prime, we had different CPUs in some models, but it may just be a voltage issue. I have run Antutu and Quadrant several times without issues though. Not sure about the D update...I I have 4.1.1.
Edit: Version 1.0.1 released, please test again and leave feedback when you can. Please let me know when you received your tab. Is it an early IO version? If this doesn't do it, I most likely will need to increase voltages a bit. Hopefully I won't have to do this so we can keep battery life at it's best.
oh s^&*, you developing here also. oh yeah! glad to see you here buddy. so you have your nexus 7 already? now that i see you here also, i will be unlocking my nexus 7, once it arrives, sooner than i thought. welcome aboard...glad to see familiar faces around here
I had the same issue. Couldn't pass the boot screen after flashing. On 4.1.1 latest update as of July 15th
Sobai said:
I had the same issue. Couldn't pass the boot screen after flashing. On 4.1.1 latest update as of July 15th
Click to expand...
Click to collapse
Thanks, I am dying to take a look at a log to see how I am so lucky to have it working! I've added LastKMSG.zip to the OP. If someone with a booting problem can do the following, I would really appreciate it:
1) Put LastKMSG.zip on your /sdcard along with the newest kernel zip
2) Flash the kernel zip
3) Wait for it to boot, give it a few seconds and then hold power down to reboot if it doesn't do it on its own.
4) Go back into recovery and flash LastKMSG.zip
5) Flash another booting kernel or your current rom to recover.
6) Boot and retrieve the file /sdcard/last_kmsg
7) Attach the log here or PM me with a dropbox link or whatever.
Thanks!
Just got some good news from a gentleman that didn't have enough posts to share with us here yet, so he PM'ed me and said that I can share the details of his experience.
First report was more of the same, sounded familiar, more bad news...
Flashed your kernel and couldn't boot pasted Google screen. Restarted in to boot and couldn't get into recovery. Was stock rooted on the latest 4.11. Went back to stock. Looking forward to trying again, now I'm on Modaco's latest. I'll let you know how it goes.
Next report was good using the latest version in the OP. Not sure, but this may help others.
Thanks! This kernel is fantastic! Makes this thing a real beast! Sorry I didn't give you the info you asked for! I got it Thursday from GameStop. The problems may have stemmed from the fact that I updated to 4.11 , rooted then side updated the newest little update and then ran a su zip to regain root (Paul o' Brian ROM) . I was also on his first cwm and then updated to his new one after I started from scratch. Loaded up his new ROM, rebooted then applied your 2nd kernel and this thing is hitting 15626 in CF benches!
Not sure what is going on, but I can't explain it. It may be my 2nd version of the kernel that fixes it, but I am not sure since I haven't seen a log yet. I suppose something may be jacked up with the early versions of recovery or roms, but the I was using the the same early versions when I tested just fine....maybe folks are losing recovery and don't realize it? I did the second step to keep recovery that is now automated in r2. If anyone has any ideas, let me know.
New version released
New version released...see OP. GPU OC to 446MHz (up from stock 416)
Looking for more feedback
_motley said:
New version released...see OP. GPU OC to 446MHz (up from stock 416)
Looking for more feedback
View attachment 1204164
Click to expand...
Click to collapse
Just out of curiously, would you ever try 520mhz for the gpu, to try to get it to t30 speeds? Or maybe would you consider some kind of app interface like extweeks for the galaxy s2 & s3 to control the GPU clock speed and maybe voltages instead of different kernels. As I would personally love to get the GPU to about 460-500mhz Anyway when I get my n7 (hopefully in a day or two) I can't wait to try this out (I am spoilt by the much more powerful 440mhz mali-400mp in the s3, so I would love to try to narrow the power difference between the devices GPU wise)
Nice man! The new versions fixed everything boots great! Now if we can just figure out how to make the Overclock stick after you turn the screen on/off. I'm not sure how to tell if the GPU OC is sticking.
Sent from my Nexus 7 using xda app-developers app
danielsf said:
Just out of curiously, would you ever try 520mhz for the gpu, to try to get it to t30 speeds? Or maybe would you consider some kind of app interface like extweeks for the galaxy s2 & s3 to control the GPU clock speed and maybe voltages instead of different kernels. As I would personally love to get the GPU to about 460-500mhz Anyway when I get my n7 (hopefully in a day or two) I can't wait to try this out (I am spoilt by the much more powerful 440mhz mali-400mp in the s3, so I would love to try to narrow the power difference between the devices GPU wise)
Click to expand...
Click to collapse
Sure, we may push the GPU OC version a bit, but I always like to walk before we run to see how things go. I would like to monitor heat output, battery usage etc. and then move forward in steps. I am very happy with it right now, but dynamic configuration would also be cool. Let me know what you think once you have it hand.
Clienterror said:
Nice man! The new versions fixed everything boots great! Now if we can just figure out how to make the Overclock stick after you turn the screen on/off. I'm not sure how to tell if the GPU OC is sticking.
Click to expand...
Click to collapse
Awesome, glad to hear it! I don't think I see this issue with the OC sticking after you turn the screen off/on, but I will do more checking after work today.
_motley said:
Awesome, glad to hear it! I don't think I see this issue with the OC sticking after you turn the screen off/on, but I will do more checking after work today.
Click to expand...
Click to collapse
Thanks a ton! Yea if you go into setcpu and make it 1.6 then turn the screen off then on (unlock) set CPU slider still shows 1.6 but if you read under that the smaller text says its actually set at.1.3 again. It seems to be a problem with the Atlantis kernel also something to do with hardcoded CPU freqs I think. Oh I wanted 5k soooo bad rofl got this twice rofl.
Sent from my Nexus 7 using xda app-developers app
Clienterror said:
Thanks a ton! Yea if you go into setcpu and make it 1.6 then turn the screen off then on (unlock) set CPU slider still shows 1.6 but if you read under that the smaller text says its actually set at.1.3 again. It seems to be a problem with the Atlantis kernel also something to do with hardcoded CPU freqs I think. Oh I wanted 5k soooo bad rofl got this twice rofl.
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
I've just made profiles that automatically set the clock to 1.5 when the screen turns on again and back to 1.5 when the screen turns off.
Edit*
Just tried the newest version and it failed to boot. Got stuck at the Google Logo. Here is the last_kmsg. Hopefully it helps
(had to put a .txt extension on it btw. Uploader wont let me upload w/o extension)
The Nexus 7 GPU is better than the Transformer Prime due to the faster RAM, so more bandwidth? If I'm correct? Thats why we see a higher Nenamark score at a lower clock?
This kernel looks very promising, excellent work! How much "play" have you had with upping the voltages, before the battery quits? On my TF, I can only go so far before the battery cannot provide enough juice, and it freezes on me. It would be interesting to know for people who want to OC really high. Does anything above 1.6 GHZ actually boot (heat and battery drainage aside)? It would be nice to OC up to 2.0 GHZ, if only for a proof-of concept. Finally, what are the temps you are getting on the higher clocks? It sounds like overheating may start becoming a real issue, and I was just curious.
The ram disk version rendered my tablet unbootable had to flash the Atlantis kernel from fast boot to get it back up and running.
Sent from my Nexus 7 using Tapatalk 2
Good work there, I would suggest adding Smartassv2 as well since it has been a good choice for many dev
I for the life of me can't get this kernel to OC. Tried System Tuner, Setcpu etc. Max only reads 1300mhz nothing shows higher beyond 1300. I have no clue what the deal is. I've tried wiping also. Even tried Atlantis' kernel. on his, it won't allow me to set anything. Max shows 0 and Min shows zero. I am running Pauls Modaco Jr3 and even tried it on EOS' new release. I'm beginning to wonder if its something diff internally. Anyone have any guesses?Also showing root as setcpu requests superuser permissions.
This is what my device shows
Board: grouper
Product: nakasi
Model: Nexus 7
Device: grouper
Build: JRO03D (Modaco Custom ROM Jr3)
google/nakasi/grouper:4.1.1/JRO03D?402395:user/release-keys
Manufacturer:asus
Brand:google
CPU ABI: armeabi-v7a
Kernel
Linux version 3.1.10-motley+([email protected]) (gcc version 4.6.3 (GCC)) #6 SMP
PREEMPT Tue Jul 17 00:52:59 EDT 2012
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
"I Don't Always Run Custom Kernels. But When I Do, I Run Vindicator"
-Worlds Most Interesting Man
Pushbullet Tag: vindicator
Vindicator OTA Updater App: https://play.google.com/store/apps/details?id=com.mcswainsoftware.vindicator.ota
if there are any bugs, contact developer Jacob
You can also follow me on G+ if you would like:
[email protected]
Intro:
This is the first kernel I've ever developed. I just started developing on android a few months ago so I'm brand new to this. I don't consider myself a developer, I'm just good at figuring things out, all credit goes to the real hard workers coming up with original ideas like Franco, Imo, Flar and Faux. Initially this was built as a kernel to compile with my ROM I'm working on but I decided I would let others get a chance to use it as well. I hope you like it and I won't be offended if you hate it. All ideas are welcome and I'll try to help as best I can. If you wish to use this kernel in a rom , feel free! Although I would love it if you let me know just for my own curiosity.
For those looking for a similar experience, but much closer to stock, I suggest giving Zen Kernel a try!
Goal:Keep kernel as lean as possible while adding certain, desirable features and optimizing for maximum performance and battery life. The default settings should be optimal for a balance of battery and performance without a need to tweak.
Disclaimer:If your phone blows up, its not my fault. If your phone somehow gains perpetual battery life, I'll take full responsibility.
Features:-Zen Kernel Base
-Android 5.1
-BFS Cpu Scheduler (Ported By @bbedward)
-Latest Linux 3.10.x
-Compiled With Uber ToolChain 6.0
-Compiled With Ofast, Strict-Aliasing, Graphite, A15 Tweaks, And Loop Nest Optimizations
-Various Other Build Optimizations
-Optional GPU OC To 700Mhz.
-GPU Initial Freq. Is 110Mhz Instead Of 240Mhz Saving Power.
-Additional GPU Steps
-CAF Power Saving Patches
-CPUIdle Driver Updated To Linux 4.0
-Slub Allocator Updated To Linux 3.18
-GPU UnderVolted
-Workqueue Updated To Linux 3.18
-Init Updated From Upstream
-Power Efficient Workqueues
-Low Power Ram Mode Enabled
-Kernel Same Page Merging
-ZenDecision Quad Core Driver
-Hotplug Affinity Enhancements
-Kexec Hardboot/MultiRom(See FAQ For Help)
-UKM Built In And Modified. Just Install Synapse App.
-Savocas Color/Gamma Control
-Lowered Regulator And Screen Voltages
-Lowered Screen Clock Speed
-Lowered Retention Voltages
-Moto QuickWakeup
-Faux's Simple GPU Governor
-Frandom (Efficient Random Number Generator)
-Hardware Floating Point Processing
-ZRam
-ZSMalloc
-I2C Min Freq. Reduced
-Cruft Free
-Slimmed Down(Increased Size Is Due To Optimizations & UKM Not Bloat)
-Tons Of Debugging Removed
-Many Misc. Optimizations
-35mhz Min Freq, 3.09ghz Max
-Several WakeLocks Removed, Such As Sensor_Ind and hsic.
-MPDecision Disabled By Default
-MSM HotPlug
-Mako Hotplug
-Adjustable Thermal With Lean Kernel Mods
-IntelliActive Governor Added
-FIOPS, ROW & BFQ IO Schedulers Added
-Tons Of IO Fixes/Performance Boosts
-No Force Encrypt. Changed To Encryptable.
-Crypto Optimizations For Enhanced IO Throughput When Encrypted
-Voltage Control
-Westwood TCP Algorithm
-PIE & HHF Network Schedulers(reduced latency)
-Tons Of CAF Commits
-Merged In Most Of Franco's Code
-Merged In Parts Of Faux123's Code
-Merged Significant Portions Of Lean Kernel Code
-Optimized RWSEM
-Many Parts Pulled From Upstream
-Merged In All CAF And Franco Interactive Commits Into Interactive
-Francos Conservative Governor
-CPU Boost Completely Removed(Replaced With Franco's)
-Wake Gestures
-F2FS Support
-LK Config
-Vibration Control
-Asynchronous FSync
-Init.D Support
-Potentially Something I Forgot...
Downloads:
[AFH] Kernel: https://www.androidfilehost.com/?w=files&flid=25836
Downloads also through app and pushbullet
Amazing Donors!:
JackPollard
Maybelle
Credits:
Imoseyon
bbedward
Flar2
Franco
Faux123
Linaro
Code Aurora Foundation
Cl3Kener
Engstk
Yank555
Mistertac (Best Tester Ever)
RIPng(DespairFactor)
Neobuddy89
apb_axel
Google
Motorola
If I Missed You Lemme Know!
XDA:DevDB Information
Vindicator Kernel, Kernel for the Nexus 6
Contributors
Xileforce
Source Code: https://github.com/XileForce/Vindicator
Kernel Special Features: I'm special.
Version Information
Status: Stable
Current Stable Version: 2.3
Created 2015-02-06
Last Updated 2015-05-3
Changelog:
1.0:
-Merged Latest Lean Kernel Code
-Merged Latest Franco Code
-Franco's Thermal Management Replaces Thermald
-Zram ported from Linux 3.19 upstream Using LZ4
-VM Memory Tweaks. (Vfs cache, swappiness,etc)
-I2C min frequency reduced from 50mhz to 19.2mhz
-Retention voltages dropper further
-Removed most Tracers
-Reduced Several Regulator Voltages
-Various CAF Patches
-Disable IO Stats
-Disable More Debugging
-Disable Gentle Fair Sleeper(better performance)
-ZSMalloc ported from Linux 3.19 upstream
-ZPool Ported from Linux 3.19 upstream
-Cut DMA latency in half
-Optimize SFCK Compression
-Reduce Swappiness
-Optimize Dirty Ratios
-Disable HSIC_Host wakelock by default
-Reduce Wlan wakelocks further
-Increase Bark/Pet Time
-Possibly More I Missed.
1.1:
-Savocas New Color/Gamma Control
-Lowered All Regulator Voltages Across The Board
-Lowered Screen Voltages And Screen Clock Speed(no detrimental effects noticed yet)
-Add Under clocked and Over clocked step for L2Cache
-Add 110mhz And 430Mhz GPU Slots
-Fix Simple On Demand Governor
-Additional Build Optimizations
-Integer Square Root Optimizations(3x faster)
-Lower GPU Bus Frequency @ 700mhz(battery and stability)
-Potentially Reduce BlueSleep Wakelock(testing report back please)
-Remove IO Debug
1.2:
-Merged Latest LeanKernel
-Added Option To Disable BlueSleep Wakelock Via Terminal
-Reduced BlueSleep By Default
-Readahead Optimizations
-More Voltage Reductions
-Power Suspend Updated To 1.7
-OC SlimBus
-Revert L2 OC
-Latest Franco Merged In
-Update To Linux 3.10.69
-Fix Ramdisk Issues
-Raise InteractiveX Default Screen Off To 730Mhz
-Lowered Power Draw Further At 35mhz
1.3:
-Added Motorola Quick Wakeup
-UKM Built In. Use Synapse App
-Added Aggressive Build Optimizations
-Merged In New Lean Kernel
-Greatly Reduced GPU Power Draw
-Added Bricked Hotplug
-Added MSM Limiter
-FSync Toggle
-Optimized LZ4 A Bit
-Some CAF Patches
-Increased Available Entropy
1.4:
-Merged In Latest Franco Code
-Removed Bricked Hotplug
-Defaulted Power Aware Scheduling On(Adjust In LkConfig)
-Added Power Efficient Workqueue(Better Battery Life)
-Optimized Timer Code
-Added Westwood TCP Alg.(Best One IMO)
-Updated UKM To Latest
-Updated MSM Limiter
-Numerous CAF/Linaro Patches
-Screen Power Draw Reduced Further
-USB Fast Charge
-Various Code Optimization Patches
-Added Toggles For Arch Power And Gentle Fair Sleepers
-Network Speed Tweak
-Don't Force Sync On Suspend
1.5:
-Kexec-hardboot/multirom support(Huge thanks to team member @jamcswain for porting that!) See FAQ For Help.
-Merged Lean 1.17
-Update To Linux 3.10.71
-Optimize Low Memory Killer For ZRam
-About 50 CAF Patches For Numerous Things(Thanks Neobuddy)
-WiFi Patches
-Crypto,IO,Memory Optimizations
-Entropy Optimizations
-DT2W Fixes
-Screen,GPU Patches
1.6:
-Android 5.1 (Massive Thanks To Imoseyon for merging it in)
-Latest Lean Merged
-Latest Franco Merged
-Mako Hotplug Updates
-Intelliplug V4
-Misc Fixes
-Default Power Aware Scheduler Off Again (Change In lkconfig)
1.7:
-Merged Latest Lean
-Merged Latest Franco
-Ramdisk Fixes For Roms(All Imoseyon)
-IO Boosts
-Updated Linaro ToolChain
-Boot Time Speedup(Jamcswains idea)
-InteractiveX Tweaked(Franco's Idea)
-Numerous CAF Patches
-Mako Hotplug Updates
1.8:
-Merged Latest Lean
-Merged Latest Franco
-Switched Toolchain To Custom Compiled Linaro
-Speed Up Boot Further
-Tons Of CAF Patches
-Audio Fixes/Patches
-800Mhz GPU Step
-MSM Limter Removed
-Added Moto Predictive Touch Driver(Better Responsiveness)
-Updated FB Notifiers
-Disabled MPDecision By Default. Mako Is Default Now
-FIOPS Is Default IO Scheduler Now
-Added Moto Low Memory Killer Optimizations
-CPUfreq and Ext4 Optimizations
-More Debugging Disabled
-Various Other Optimizations And Updates
-Update To Linux 3.10.72
-Probably Stuff I Forgot
1.9:
-Merged Latest Lean Kernel
-Fix USB OTG
-Fix Wake Gestures
-Default To QuadCore Mode For Mako
-Ensure 35Mhz Is Min Freq. on Boot(Fixes Weird Issue)
-Modified UKM/Synapse To Control Wakelocks (Misc Tab)
-Merged Latest Hydra Kernel Changes/Patches
-Fix Battery Drain On BlueTooth
-Frequency Mitigation Preventer V2 (In LKConfig)
-Stability Fixes
1.9.1:
-In Call Audio Fix
1.9.2:
-Updated With Official Multirom/Kexec Hardboot Patch
2.0:
-Merged Latest Franco And Lean Code
-Linux 3.10.73
-Several Memory Leaks Fixed
-Reboot/Bootloops Fixed
-!00's Of Patches
-SELinux Permissive By Default
-Compiled With SaberMod 5.0
-Screen Frequency Reverted To Stock
-Tweaked Interactive Touchboost Parameters Further
-Replaced IntelliPlug With MSM Mpdecision
-Added Back MSM Limiter
-FB Notifiers now Enabled By Default. Toggle Added To Synapse
-Merged In Some Hydra Kernel Ramdisk Fixes
-GPU OC Reduced Back To 700Mhz
-Add Power Aware Scheduling to Synapse (CPU Settings Page)
-Fix Synapse To Display CPU Bin On Front Page
-Revert FastBoot Mods For Now (Buggy)
-KCal Fixes
-MSM_HSIC WakeLock Now Enabled By Default With Divisor Of 5 (Change In Synapse Or LKConfig)
-Mako Hotplug Load Threshold Set Back To 80
-Misc Optimizations
2.1:
-Completely Rebuilt From Scratch Upon Zen Kernel With Input From bbedward
-Some features may be missing atm and may get added back in down the line.
-BFS Cpu scheduler. IMO a significant upgrade over CFS, the standard one used by almost every kernel. Should give better battery life and performance. THIS IS ONE OF THE BIGGEST CHANGES A KERNEL CAN MAKE
-Cleaned up the source and fixed issues.
-EXT4 and F2FS updated with upstream commits.
-Per CPU VMA Caching From Upstream
-BFQ and ROW IO Schedulers
-Touchboost Adjustments For More Butter
-Fauxs Simple GPU Governor
-Lowered the default voltage on 1.497ghz 10mv by default
-Compiled With Ofast Instead of Os (Ofast Is the heighest gcc optimization level, one step above O3. Os optimizes for size, rather than speed.)
-Compressed with optimized XZ rather than LZ4 to keep size down
-Latest lean and Franco merged in.
-Adaptive Low Memory Killer enabled
-So much stuff....and I honestly have no idea on how to write a changelog for a rebase...its an entirely new kernel...
2.2:
-Compiled With UberTC 6.0 (Figured We Would See How It Compares To SM 6)
-Compiled With Graphite Optimizations
-Compiled With Loop Nest Optimizations(An Extremely Aggressive Optimization)
-Compiled With loop-unroll-and-jam(A companion optimization to loop nest also aggressive)
-Small GPU Tweaks
-Greatly increased encrypted IO Performance
-Arm Specific Optimization Patches
-Added Heavy Hitter Filter(Another Network Optimization That May Also Reduce CPU Usage)
-Added Proportional Integral Controller Enhanced(Yet another network optimization algorithm designed to reduce latency and increase efficiency when doing latency sensitive things such as streaming)
-Optimize boot/compressed for Krait
-Addition Branch Optimizations and Inter Procedural Optimizations
-Support CM12.1 Ramdisk
-Optimize ROW and Deadline
-Add Bluesleep Wakelock Toggle
-Reduce Wlan_Ctrl Wakelock
-Default Wlan_rx wakelock divisor to 5
-Default msm_hsic divisor to 6
-Fix lkconfig frequency stuff
-Default below 40% frequency changing OFF
-Cleanup frequency mitigation stuff in lkconfig.
-Add Westwood
-Use amended interruptible threads (reduces cpu load)
-Disable add random on IO
-Reset cpu dma latency to stock...idk what it does so i shouldnt touch it...
-Revert Ram OC (IDK if it even worked)
-Add smb135x wakelock toggle
-A GPU Patch
-Raise default touchboost to 500ms.
-Optimize memcpy and memmove
-Significantly Optimize Console Framebuffer
-Enable non-cacheable streaming enhancement
-Add GPU Compile Optimizations
-Disable a lot more debugging
-Boot with 2.649ghz max freq for stability
-Add OC up to 3.033ghz. Highly unstable IMO but its an option for the brave.
-Cleanup Ramdisk
-Raise voltage a bit on 2.88 for stability.
-Disable useless resource counters to save processing power and battery.
2.3:
-Update CPUIdile Driver and CPUIdle Governors almost completely to linux 4.0(Several Years Worth Of Commits)
-Updated CPUFreq Driver Nearly To Linux 4.0
-Update Suspend/Sleep Driver Mostly To Linux 4.0
-Update SLUB Allocator To Linux 3.18
-Update Block(IO Stuff) From Upstream A Bit.
-Upstream Scheduler Patches
-3.09Ghz CPU Step Added (Likely Quite Unstable) Some People Like That Stuff
-Amperage On 3.03Ghz bumped up a tad for stability.
-Linux 3.10.75
-Frandom random number generator added(Extremely Fast Random Number Generator)
-Power Efficiency Patches From Code Aurora
-Fixed Crash When Switching CPU Govs.
-BFS Updates!
-Update Ondemand to Linux 3.18
-Default OnDemand To Simms22's Preferences
-Merged Latest Franco Code
-Merged Latest Lean Code
-Merged Latest Zen Code
-Franco's Conservative governor updated
-Some Interactive updates
-Color control updates
-ARM Specific Updates
-F2FS Updates
-GPU Driver Updates
-Memory Leak Fixes
-Stability Fixes
-Updated ToolChain
2.4:
-Updated To Linux 3.10.77
-Merged Latest Lean Kernel
-Merged Latest Zen Kernel
-Update Workqueue To ~ Linux 3.18
-Enable Ram To Enter Low Power Mode
-Update mm.h And Memblock from upstream
-Default IO Scheduler To BFQ. Its Been Tested To Be Best For Interactivity
-Upstream Init A Bit
-A Few Patches To SMP
-Upstream Cgroups And Memcg Significantly
-Disable RunQueue Stats. Pointless Bloat and CPU Overhead only needed for mpdecision
-Added Power Efficient WorkQueues Patch From Upstream(This Gives better battery life at the cost of a likely unnoticeable performance hit. Enabled by default. Toggle in synapse CPU settings page)
-Hotplug Efficiency Patch(Optimizes Hotplugging To Handle The Transfer Of Processes From One Core To Another Much Better)
-ZenDecision Added
-Added A Toggle For Mako(Currently Only Works To Disable Mako. Ill Work On It Further In 2.5 Credit to bbedward for this
-GPU Tweaks To Make It Smoother
-UnderAmped(Reduce Current For Every Frequency Up To 2.7ghz. Should Save Power. Experimental)
-Added KSM Tweaked For Android(Disabled By Default, Scans Few Pages, and does so very rarely. I didn't notice a battery hit with it on. Optimizes ram use)
-Franco Kernel Updater Profile Updates
-Ramdisk Modifications(May Fix Some Rom Issues)
-Fix For Ondemand Crashing(Hopefully)
-Misc Tweaks & Patches
-Hotplug Affinity Fixes
-Various Power Saving Patches
-Optimize Copy_Page For Modern Arm Processors
-Do Jiffies Conversions At Compile Time Rather Than Runtime(Saves The Cpu Work)
-Optimize For Our L1/L2 Cache Size
-Allow Options To Be Passed To Memory Barrier Instructions
-2 Patches To Improve File System Performance
-HRTimer Optimizations
-Make Binder Mutex Realtime To Reduce Chance Of SurfaceFlinger Being Blocked
-Keep Track Of ASID Allocations And Try To Reuse Them In Certain Cases To Improve Performance
-Don't Compile CPUIdle Ladder Governor. It doesn't get used anyways.
-Allow Rescuer Thread To Do More Work
-Reduce Runqueue Lock Contention
-don't use compound_head() in virt_to_head_page() this showed around a 1.8% performance improvement in some cases
-Small MultiCore Scheduling Improvement
-Definitely Some Stuff I Forgot
FAQ's
1. How Do I Enable Mako Hotplug?
To enable mako hotplug use your favorite kernel control app like faux or trickster. As of 1.8 it is the default hotplug. In trickster you have to turn off both mpdecision and intelliplug. In faux you need to simply select User Control in the Hotplug Section. The hotplug can be configured using Franko Kernel Updater App.
2. Does This Work With CM12 Theme Engine?
Yes, this works with CM12 Theme Engine and should work on all ROMs properly.
3. How Can I Force All 4 Cores Online All The Time?
First you must enable mako hotplug. Then you need to use Franco's kernel updater app or another app that allows you to tweak mako hotplug settings. In fku app select CPU manager then hotplug control. Change load threshold to 0. Additionally if you just want to make it use 4 cores more often. Lower this number below 80 as desired. This should also be possible to tweak via terminal however I've never used that method.
4. Does This Have D2W, S2W, etc?
Yes, those are part of LK which means they are include in this kernel.
5. Help! I think its making me bootloop!:
This may only apply to specific ROMs and I'm unsure ofnwhy it would change anything but users have reported this to fix the issue. If you are trying a fresh install of a ROM boot on stock kernel first, reboot, then install this kernel.
6. You Broke My Phone! Fix It!:
It will be quite hard for me to figure out what is going on if you don't provide details and a log of what happened. To get a log use any file manager with root support and navigate to sys/fs/pstore I then need the console one.
7. What Kernel Tweaking App Should I Use? What About For Tweaking Screen???:
I now Use synapse as my goto app for kernel tweaking since version 1.3. To control the screen I use the app made by Savoca who created the color control we use http://downloads.codefi.re/savoca/kcal
8. Why Add Zram? We Already Have 3gb Of Ram!
Zram was added in build 1.0 as an experiment of sorts to see how much is was actually being used. V 1.0 introduced a bunch of tweaks to the kernel that essentially make it use more ram in order to give better battery life and performance. Zram was put in place to offset this in a way.
9. Wut Is A LZ4?
LZ4 is a compression algorithm used by the kernel. LZ4 is currently the fastest supported option in the Linux kernel and had to be ported from upstream. It is significantly faster than XZ compression which is what we used prior. The downside is it results in slightly larger file sizes due to a lower compression ratio. However with modern hardware this should be moot. The gains should theoretically be noticed as a general performance bump. Boots should be faster. IO should be marginally faster. Anything that's compressing or decompressing stuff, such as ZRam and encrypted devices will utilize this in a big way. Because its compressing and decompressing so much faster it can also be assumed it is saving battery via less CPU cycles.
10. What Is Strict Aliasing And Why Should I Care?:
One of the big things Linaro does with improving Android's performance is fixing violations of what's known as "the strict aliasing rule." A pointer is said to alias another pointer when they both refer to the same location of memory. This is OK and not an uncommon thing to do. The strict aliasing rule is that pointers of different types should never refer to the same location of memory (aka alias each other). Strict aliasing allows a compiler to make some assumptions when compiling and optimizing code that it otherwise couldn't. It's actually one of the biggest optimizations you can do and it is fairly hard to add which is why most people don't. Here's a nice read up on it http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html#benefits
11. Come on man. 35mhz is pointless bro!:
A common misconception is that if two frequencies run at the same voltage. They use equal power. In fact this couldn't be less true. The equation for power draw has four variables. Two of which are frequency and voltage. Essentially it is the frequency multiplied by the square of the voltage. Then you would take that and multiply it by a few other things such as capacitance. However that is irrelevant for our purposes as it will not effect the relative results. This means that 35mhz running at 500mv will use about 3x less power than 98mhz at 500mv. Now we say well what about compared to 300mhz? I can stably run that at around 650mv. Maybe slightly less. This equates to about 15x less power usage at 35mhz. Well now that we know that. Who cares? Its not like 35mhz will even get used. Its too low! I beg to differ. I would almost guarantee that if you are not running mpdecision 35 MHz will be within the top 3 most used frequencies. Most likely the top used below sleep. And every time it uses that over 300mhz you are saving 15x the power. Additionally 35mhz also runs at a cache frequency of 35mhz as opposed to 300mhz cache frequency and runs a lower bus speed/voltage saving additional power. The same goes for 98mhz. Hope this helps clear things up.
12. How Do I Disable BlueSleep Wakelock?
Open terminal emulator app. Type su then hit enter then type echo 0 > /sys/module/wakeup/parameters/enable_bluesleep_ws all on one line. It won't say anything but if you turn on Bluetooth and check your wakelocks you shouldn't see the wakelock there anymore. This needs to be set on each boot currently. If you experience Bluetooth connectivity issues don't disable this. To enable it again either reboot or run the same command with a 1 instead of a 0.
13. How Do I Use MultiRom???:
To use multi ROM first you must download the MultiRom App from this location http://tasemnice.eu/bordel/MultiROMMgr-v1.180.apk the play store version doesn't work with shamu yet. Then you will need to open it, go to settings and tap the version number until you are a developer. Then click override manifest URL and for manifest URL enter http://tasemnice.eu/multirom-test/manifest.json the. Go back to the main page. You should now have MultiRom and recovery boxes checked. Click install, reboot etc. To install a ROM. Download a ROM you like, go to twrp, click advanced,MultiRom,add ROM. Select internal storage and the Your zip file. Flash it but don't reboot! After that go back and select "list ROMs" select the ROM u just flashed still and click flash zip and select your gapps,supersu etc. After that simple reboot and select your new ROM on boot use the MultiRom app to manage your ROMs.
More will be added as they come up and I think of them.
Configuration Guide:
The following can be done using your favorite kernel tweaking app. I use synapse.
Clock Speed:
To begin I prefer to leave my max clock speed at the stock 2.649ghz. Set min CPU as low as it can go. As of current release this is 35. For the adventurous you can try 2.88ghz. Often I bump the voltage 12mVolts on 2.88 to be safe.
To find your CPU binning run this command in terminal emulator OR look at the first page in synapse near the bottom:
su (enter)
cat /proc/cpu/msm_acpu_pvs (enter)
(Put a space between cat and /proc)
note that the number may be displayed at the beginning of the next line.
It will then display a number from 0-15. 15 being the best. Don't stress over it too much if you score low, its not the end of the world. It just means you need marginally more voltage to run each frequency.
GPU:
As of Alpha 1.3 the GPU can now be over clocked to 700mhz. This is completely optional. To verify your over clock change the GPU governor to performance and see if it spikes to 700 every so often. If it does it worked! If it doesn't you may need to set the frequency to something else then back to 700 again. It remains to be seen what kind of benefits the GPU over clock will give but it is there for those who want it. The recommended GPU governor is the stock msm adreno one. If you encounter lag in games you can try changing it to performance temporarily while playing that game. Simple on demand is a more performance oriented governor.
Governor:
Most people will probably want to just leave this set to interactive. Its a really good governor that is being actively devolped by CAF, Google, and Franco. It also hooks into Francos CPU Boosting interface. Its "smarter" than OnDemand and generally considered to offer better battery life. If you want even more smoothness some consider OnDemand to provide a bit better performance, however you may get slightly worse battery life. This is because OnDemand ramps up to max frequency when there's is load put on the CPU and then slowly works its way down. Interactive scales through the frequencies on the way up and down which saves battery life but prevents it from jumping to max speed as fast if it is needed. Simms22 recommends using the OnDemand governor with "upthreshold" set to 98 and the sampling rate set to 15000. That is the default setting of the Trinity Kernel. Mistertac made the great suggestion of turning the max screen off frequency down to 600mhz if using the interactiveX governor. This will prevent any misbehaving apps from keeping CPU ramped up while screen is off and give better idle drain. The actual number you would have to type in would be 652800 for the screen off frequency. The Conservative Governor is greatly modified by franco, Its no longer a super slow governor as it once was. It also hooks into his cpu boost control interface meaning you get cpu boost when using it. Conservative prefers the lower frequencies, however so if you find yourself having lag, you may want to switch to another.
PowerSuspend:
The only working options in V1.6 of the PowerSuspend driver are lcd_panel and Userspace which can be found in the miscellaneous section of FauxClock. I suggest leaving it at the default choice of LCD_PANEL. In FauxClock if you navigate to the cpu idle/stats area you will be presented with more options. You should see a list of C-states. For example C0: wfi and C1: retention. These are essentially low power states that the cpu can enter to save power. The higher the C number the deeper the sleep. Last I heard, the optimal configuration was to enable C0, C1, and C3. Paired with lowered Retention voltages, this should give you a very low idle drain.
Hotplugging:
Next go to hot plugging section and disable MPDecision(make poor decision) and enable intelliplug or, enable Mako Hotplug(Franco's) by either selecting user control as your hotplug, or disabling both mpdecision and intelliplug. Tweaking for them is split up below.
IntelliPlug:
FauxClock allows you to further configure intelliplug. If you want more battery set it to Conservative (4) mode which will hotplug the CPU more conservatively and save you battery, essentially this means it will use less cores if it can. For most people, leaving it on Balanced (4) mode will be fine. If you want further battery savings you can set it to EcoPerformance (2) or even EcoConservative (2) which will only use a max of 2 cores. IntelliPlug is able to use a single core unlike Mako Hotplug.
Mako Hotplug:
As far as I know the only way to tweak Mako Hotplug is either through the terminal app, synapse or through Francos app. In Francos app select cpu manager, then Hotplug Control. The main one you will need is load threshold. The default is 80. The higher this number, the more load the cpu needs to be under before it will plug the 3rd and 4th cores. 80 is actually pretty good value for most people and it will use the extra 2 cores when it really needs them. If you want to force all 4 cores on for whatever reason, you can achieve this by setting the load threshold to 0. This will effectively disable hotplugging. Of course you can always find a middle ground as well.
Via Terminal:
The sysfs interface for mako hotplug is...
/sys/devices/virtual/misc/mako_hotplug_control
To adjust... Use echo commands...
Ex:
echo 0 > /sys/devices/virtual/misc/mako_hotplug_control/load_threshold
The above command would set the load threshold to 0.
Thanks Rignfool!
Voltage Control:
Next go to voltage control. I'm a Bin 5 and I can use a 48mVolt undervolt without becoming unstable. Rember! Never set voltages to apply on boot until you have tested them for a few hours first! Most people can probably get away with a 36mVolt undervolt and nearly everyone should use at least a -24mVolt UV. Also remember that if you are running an over clock you may not want to undervolt that frequency. If you find yourself running into freezes or random reboots remove the undervolt!
Thermal:
This kernel comes with the latest IntelliThermal Driver from Faux123, which is a highly configurable thermal driver, as well as Franco's Thermal Driver which is the stock option. It is recommended you use IntelliThermal over Franco's if you wish to customize the values. Change this option under the Thermal Manager section of FauxClock. The optimal settings that I have found are 70 degrees for frequency throttle, and then somewhere between 70 and 80 for core throttle temp, depending on how safe you want to be. Stock is 80 degrees. Leave all cores checked for both frequency throttling and core throttling. I also leave on GPU Thermal Control, but if you encounter periodic lag in games you may wish to disable it. I also leave Core Thermal Control on as well, though I'm not entirely sure what it does lol. Also FYI, the sliders beneath those two options are showing you the current status of them, they are not sliders you can move.....trust me...I tried for like 5 minutes before I realized and felt like a moron....
I/O Settings:
For I/O scheduler select FIOPS. FIOPS is superior to the other schedulers in nearly every way. It is a scheduler designed for flash storage which is what our phones use. My testing has shown that 1536 is the best readahead buffer. Less or more is detrimental.
ZRam:
ZRam is something designed to optimize the ram of a device. What typically happens when a device runs out of space in ram is it is forced to use something called swap. Swap is normally a partition of a hard drive or ssd depending on what is available where the ram can copy some of it's contents to free up space. The problem is even the fastest SSDs are many many times slower than ram. Android by default doesn't have swap, however it does use a low memory killer which essentially goes through and clears out apps that are in ram to free space. ZRam makes a compressed partition inside the ram itself which then acts as a swap partition. Basically when ram begins to fill up. It compresses data and sticks it in a sealed off area of the ram. This let's it stuff way more stuff into ram than normal. To enable ZRam I use fauxclock. Trickster for whatever reason does not work. In FauxClock go to memory settings, then set the Zram size to 300mb and click apply disk size. Then turn it on and set on boot. You have now essentially boosted the available ram via compression!
VM Settings:
There are numerous tweaks you can do to the VM. For this I use FauxClock but IK Kernel Aduitor can do this as well. In FauxClock navigate to memory manager. The first thing to tweak is an option called swappiness. This control is used to define how aggressive the kernel will swap memory pages. Higher values will increase agressiveness. I defaulted this to 10 however the default is 60. This will use more ram but give better performance. Next is VFS Cache Pressure. This controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects. The default used to be 200. Its now defaulted to 10 meaning more ram usage but more performance. Next up is dirty ratio and dirty background ratio. Some things pass through ram and stay there for a bit until they get flushed to the flash storage. These controls essentially dictate how long it should wait before flushing to the flash storage. The longer you can delay it the better performance and battery you achieve, at the cost of ram. Setting these higher will increase ram usage but increase performance. I recommend a background ratio of 30 and a dirty ratio of 50, however feel free to tweak them as you desire.
Color Control:
Next you may want to adjust Screen RGB, value, saturation, hue and contrast. WrinkleFree over in the Lean Kernel thread did extensive testing with a professional grade $1000 screen calibration tool. You can use this app http://downloads.codefi.re/savoca/kcal to control the screen.
For the most truly color accurate screen at D6500K:
Red - 248
Green - 246
Blue - 255
If you prefer a slightly cooler screen and the tuning the iPhone uses which is D7400K:
Red - 237
Green - 235
Blue - 255
More info can be found about color calibration here: http://forum.xda-developers.com/showpost.php?p=57265483&postcount=620
As for saturation. I like to turn it up a bit and make the colors pop a bit more so I leave it around 65. But quite honestly saturation,value,contrast,and hue are going to come down to tweaking it and finding what you like most. Have fun!
These settings are meant to be used as a starting point. Depending on your cpu binning and desires you will probably want to tweak these slightly to fit your needs. I'll add more as new features get added, I learn more, and I think of stuff to add Hope it helps someone!
Sweet! Good work man.
Thanks for sharing.
It does support the CM Theme Engine, right ?
x0nar said:
Thanks for sharing.
It does support the CM Theme Engine, right ?
Click to expand...
Click to collapse
Yessir using it as we speak
Seems buttery enough. Will let you know the battery life on Bliss 2.0
x0nar said:
Seems buttery enough. Will let you know the battery life on Bliss 2.0
Click to expand...
Click to collapse
Good to hear so far. Don't forget to lower your min frequency . Also I recommend either Conservative or Interactive governors ATM as they hook into the new CPU boost. I'll be posting a full configuration guide probably tomorrow. Hope you like it.
New kernel , SUPER
Fauert said:
New kernel , SUPER
Click to expand...
Click to collapse
Hope you like it! No doubt I'll be hearing many bug reports when I wake up tomorrow
I've been testing this kernel on a few different Roms without any issues at all really so everyone should be happy with it.
If anyone gets any reboots though do try and get logs [emoji106]
Xileforce said:
Good to hear so far. Don't forget to lower your min frequency . Also I recommend either Conservative or Interactive governors ATM as they hook into the new CPU boost. I'll be posting a full configuration guide probably tomorrow. Hope you like it.
Click to expand...
Click to collapse
Looking forward to your guide.
Nice kernel. Jist one thing, may be is a feature i dnt know but only 2 cores online when i tried tu push all cores on, just stay with 2 or 1 core on. I changed the hotplug but still the same
Sent from my Nexus 6 using XDA Free mobile app
Bestplayer55 said:
Nice kernel. Jist one thing, may be is a feature i dnt know but only 2 cores online when i tried tu push all cores on, just stay with 2 or 1 core on. I changed the hotplug but still the same
Sent from my Nexus 6 using XDA Free mobile app
Click to expand...
Click to collapse
Are you trying to do this for a Benchmark?
Using the Faux app you can first set it to Intelliplug , then Performance (4) Cores and that should get you there.
If not, try setting it that way and reboot. I've noticed with this phone that I've had to reboot a lot for my changes to actually take correctly.
Cpu2 and cpu3 are stuck in performance...
And does anyone know where in sysfs to adjust mako hotplug?
rignfool said:
Cpu2 and cpu3 are stuck in performance...
And does anyone know where in sysfs to adjust mako hotplug?
Click to expand...
Click to collapse
Gotcha.. Well once Mr Xile wakes up I'm sure he'll have something for you, not sure myself.
Mistertac said:
Gotcha.. Well once Mr Xile wakes up I'm sure he'll have something for you, not sure myself.
Click to expand...
Click to collapse
I found it... And I learned a new Linux command in the process...
Haven't done a full battery test yet, but I seem to be getting the best I've seen so far.
Bestplayer55 said:
Nice kernel. Jist one thing, may be is a feature i dnt know but only 2 cores online when i tried tu push all cores on, just stay with 2 or 1 core on. I changed the hotplug but still the same
Sent from my Nexus 6 using XDA Free mobile app
Click to expand...
Click to collapse
Currently if you disable all hotplugs or if you use fauxclock to set it to usercontrol that enables Franco's mako hotplug. Thats why in an app such as faux you cannot easily force two cores online. However if you use Franco's updster app you can go to CPU manager then hotplug control and if you lower the load threshold it will hotplug more frequently. Setting this to 0 will force all cores online. Additionally as mistertac said. Using b intelliplug on either performance(4) mode or balanced(4) will use all 4 cores pretty frequently as well.
Welcome to: The One Bad Ass ROM
Hello everyone, I would like to present OBAR (One Bad Ass ROM) a ROM that I successfully built for the Note 4 is now on our LG, well for Sprint at-least. So here it is, a Stock, de-bloated, modified ROM that is based off of ZV6 to bring the absolute best performance and battery life to your phone! Hope you guys enjoy! EDIT (5/02): As of now we have our very own OBAR Kernel,
I'd like to let you know all about it so seek the second post
Stock Specifications:
Based On Stock LS997ZV6 (Nougat - 7.0.1)
Our Very Own OBAR Kernel! (See second post for details)
Rooted & Busy Boxed
De-Bloated
Magisk or SuperSU Compatible (SuperSU built in)
No Sprint Bloat
OBAR Features:
Enabled High Independence Mode
Enabled Guest Features (Max: 5)
Enabled Hotspot
Added Build.Prop Tweaks
Added Custom Kernel Adiutor
Fixed Data On Boot
Improved Net Speeds
Improved Scrolling Speeds
Improved RAM Management
Insane Battery Life
Insane init.qcom.post_boot Modifications (Improves Overall Performance/Battery/Stability)
And more I forgot...
Install:
Download
Transfer To Phone
Reboot To Recovery
Wipe System, Data, Cache, Dalvik Cache (x3)
Format System (Backup Your Internal Storage First)
Install Stock OBAR Rom
Wait About 15 min To Boot
Enjoy
Downloads:
Rom Releases
Kernel Releases
Older Versions
After Install: (Recommended)
Initial boot will boot twice.
Please allow about 15 minutes to boot up after initial boot. (Due to it being deodexed)
Recommended to wait up to five minutes on initial boot before doing anything, then do a full restart.
To get back Developer Options go in to Settings, About Phone and rapidly tap Build Number until it says your a developer.
Important Notes:
Yes there is static on boot.
For those who get stuck in a "TWRP LOOP" see here.
Don't ask if this will work on other variants I will ignore your question. I will not support other variants with this ROM, sorry. Sprint only. You can always flash it and find out.
Credits:
@me2151 - For the Official LS997ZV6 Base and root method of course!
@svadev - For the SVA Deodexing tool!
@Ticklefish - For the TickleMyAndroid Tool!
@DTDMike - For the ability to enable High Independence Mode.
@ashirviskas - For enabling the dual speaker mod.
@warBeard_actual - For the crazy init.qcom.post_boot Modifications
@Team DevDigitel - For a working base and great help!
@freeza - For teaching me how to build my first kernel!
@BackCheck - Major help with figuring out how to get the kernel to fully work properly!
Disclaimer: I do not and will not take any responsibility towards anything that happens to your phone after flashing.
XDA:DevDB Information
Stock LS997, ROM for the LG V20
Contributors
SaintZ93, me1212
ROM OS Version: 7.x Nougat
ROM Kernel: Linux 3.10.x
ROM Firmware Required: LS997
Based On: Stock
Version Information
Status: Stable
Current Stable Version: Release 1
Stable Release Date: 2017-03-26
Created 2017-02-09
Last Updated 2017-03-26
Okay guys OBAR now contains its own kernel! So I want to give you a bit of information that may help you to decide how you want to set up it up! I will always keep this post updated with all the latest version release information. Will label dates next to each new update to show what is new!
I/O Scheduler Information - GPU:
FIOPS - This is an IOPS based I/O scheduler. It will try to distribute IOPS equally among all processes in the system. It's mainly for Flash based storage.
SIO - The Simple I/O scheduler is an extremely simple scheduler, based on noop and deadline, that relies on deadlines to ensure fairness. The algorithm does not do any sorting but basic merging, trying to keep a minimum overhead. It is aimed mainly for aleatory access devices (eg: flash devices).
NOOP - The no-op I/O scheduler is a minimal scheduler that does basic merging and sorting. Its main uses include non-disk based block devices like memory devices, and specialised software or hardware environments that do their own scheduling and require only minimal assistance from the kernel.
DEADLINE - The deadline I/O scheduler is simple and compact. It will provide CSCAN service with FIFO expiration of requests, switching to a new point in the service tree and doing a batch of IO from there in case of expiry.
CFQ - The CFQ I/O scheduler tries to distribute bandwidth equally among all processes in the system. It should provide a fair and low latency working environment, suitable for both desktop and server systems.
BFQ - The BFQ I/O scheduler tries to distribute bandwidth among all processes according to their weights. It aims at distributing the bandwidth as desired, independently of the disk parameters and with any workload. It also tries to guarantee low latency to interactive and soft real-time applications. If compiled built-in (saying Y here), BFQ can be configured to support hierarchical scheduling.
BFQIO - Enable hierarchical scheduling in BFQ, using the cgroups filesystem interface. The name of the subsystem will be bfqio.
ZEN - FCFS, dispatches are back-inserted, deadlines ensure fairness. Should work best with devices where there is no travel delay.
Governor Information - CPU:
Simple Ondemand - Chooses frequency based on the recent load on the device. Works similar as ONDEMAND governor of CPUFREQ does. A device with Simple-Ondemand should be able to provide busy/total counter values that imply the usage rate. A device may provide tuned values to the governor with data field at devfreq_add_device().
Performance - Sets the frequency at the maximum available frequency. This governor always returns UINT_MAX as frequency so that the DEVFREQ framework returns the highest frequency available at any time.
Powersave - Sets the frequency at the minimum available frequency. This governor always returns 0 as frequency so that the DEVFREQ framework returns the lowest frequency available at any time.
Userspace - Sets the frequency at the user specified one. This governor returns the user configured frequency if there has been an input to /sys/devices/.../power/devfreq_set_freq. Otherwise, the governor does not change the frequnecy given at the initialization.
Blu_active - This allows you to get a full dynamic cpu frequency capable system by simply loading your cpufreq low-level hardware driver, using the 'interactive' governor for latency-sensitive workloads.
Nightmare (NEW 5/15) - This is a PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery. In addition to the SoD is a prevention because it usually does not hotplug.
Darkness (NEW 5/15) - It's based on nightmare but more simple and fast, basic configs but very complex structure. It is an updated nightmare gov and improved stability, so far it is quite stable in tests.
Chill (NEW 5/15) - Use the CPUFreq governor 'chill' as default. This allows you to get a full dynamic frequency capable system by simply loading your cpufreq low-level hardware driver. A conservative based governor that aims to provide more aggressive battery savings while screen is off.
Dance Dance (NEW 5/15) - Based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It is a performance focused governor but also blends with some battery savings.
Adreno Idler Information:
Enabled - Uses a different calculation method on top of Adreno TZ just for calculating frequency for idle to reduce the wasted power coming from stock Adreno TZ while maintaining high-performance.
Other Information:
Moved Core Control To Kernel - Moved core control from out-of-tree module into the kernel proper. Core control monitors load on CPUs and controls how many CPUs are available for the system to use at any point in time. This can help save power. Core control can be configured through sysfs interface.
Moved Core Control Trace Events To Scheduler
Added A Knob To Disable The core_ctl (Core Control) - The CPU hotplug tests does not work with core_ctl compiled statically into kernel. Provide an interface to disable the hotplug by core_ctl.
Enabled LZ4 Compression & Added ExFAT Filesystem
Fixed Various Issues
Source Code: https://github.com/SaintZ13/obar_kernel
Nice can't wait to try this out!
Sent from my SM-N920P using Tapatalk
Thanks for the new ROM! Does this add back the stock LG gallery and music player, or are those still removed?
Cubit33 said:
Thanks for the new ROM! Does this add back the stock LG gallery and music player, or are those still removed?
Click to expand...
Click to collapse
Yes there included. I accidently removed a file that connects to Sprint. Will add it later and upload!
SaintZ93 said:
Yes there included. I accidently removed a file that connects to Sprint. Will add it later and upload!
Click to expand...
Click to collapse
Thanks! Looking forward to testing.
Would you guys prefer this to be straight stock or should I mod it up?
Mod it up!
Sent from my LG-LS997 using Tapatalk
SaintZ93 said:
Would you guys prefer this to be straight stock or should I mod it up?
Click to expand...
Click to collapse
Mods are great, but I'd also be a fan of posting your base rom that is just the "stock features" you have listed above. A slim base version in addition to the modded out version basically.
Mods, mods, mods
So glad to see you over here on the sprint V20 Saint! You always put out great ROMs and you never disappoint! Looking forward to this one.
BTW, mod it up!
Thread closed temporarily at OP's request
Edit: Reopened at OP's request
Okay guys I was finally able to mod it up and make it a very worthy ROM. Enjoy!
Glad you found it useful, man.
warBeard_actual said:
Glad you found it useful, man.
Click to expand...
Click to collapse
Hey man thanks for it! Now your scaring people by being out of the axon threads hahaha
dowloading now
thanks @SaintZ93
OBAR for the note 4 was great
SaintZ93 said:
Would you guys prefer this to be straight stock or should I mod it up?
Click to expand...
Click to collapse
Mod it up. Viper4 and 3minit battery are my favorite add ons.
Some debloat is nice.
I used to run OBAR on either my note 3 or 4.
Downloaded and excited to try it out - but loving classic rom to much to try it out just yet. Soon.
Thank You
Mod the daylights out of it!! I been dying for a good one like that WETA rom but cant use it. Im always dying to try something new tho
Running good on my v20. Nice and smooth. :good::good::good:
Used to love this on my note 4 good to see u bro
Hello everyone,
after countless hours of work here it finally is. The first working EAS kernel for our beloved HTC U 11.
Important question: What is EAS?
Energy Aware Scheduling (EAS) is an enhancement to Linux power management, unifying CPU power control under the Linux kernel. EAS extends the Linux kernel scheduler to make it fully aware of the power/performance capabilities of the CPUs in the system, to optimize energy consumption for advanced multi-core SoCs including big.LITTLE. With EAS, the Linux kernel will use the task load and a CPU ‘Energy Model’ to control task placement to select the optimal CPU to run on.
Google thinks, EAS is the way to go for the future. With this kernel you can get pixel (2) experience even before the pixel (2) is released.
Interesting links for further research:
http://www.linaro.org/blog/core-dump/energy-aware-scheduling-eas-progress-update/
https://developer.arm.com/-/media/d...overview_and_integration_guide_r1p3.pdf?la=en
DISCLAIMER:
I had to rewrite and cut out a lot of code to get EAS working. Due to this the prebuilt WLAN and texfat modules are no longer working for this kernel. There are conflicts because I moved to far away from HTC´s codebase.
Because of this I had to compile the WLAN driver from source and integrate it as a module in the kernel zip. To get texfat working I had to built the exfat-nofuse driver from @dorimanx into the kernel.
To allow the kernel to fully operate we need to disable HTC´s PNPMGR.
That means in case you want to go back to a HMP kernel you will have to either backup the wlan module and the pnpmgr files manually or do a nandroid/dirty flash your rom (which is way easier).
This also caused WLAN calling not to work!
Features:
- EAS for 4.4 with patches from 4.9 eas-dev
- Upstreamed to latest 4.4.170
- Rootless interface supported
- Enabled NOOP, DEADLINE, CFQ, MAPLE, TRIPNDROID and BFQ IO scheduler
- Enabled advanced TCP Congestion Control
- Included GPU Boost
- S2S across navbar area
- KCAL color calibration
- Backlight Dimmer
- Button Mapper Support
- Fsync On/Off support
- Green Pulsating Notification LED @tbalden)
- Fingerprint Double Tap to sleep support @tbalden)
- Button Light Notification from @tbalden
- Gradient Charging LED from @tbalden
- Squeeze Control (squeeze to wake/peek/sleep; squeeze to swype) from @tbalden
- Flashlight notification from @tbalden
- Vibrating Notification reminder from @tbalden
- Notification Boost from @tbalden
- Generic wakelock blocker
- Completely rewritten CPU-Boost for EAS (thanks to @RenderBroken) along with Dynamic Stune Boost from @joshuous
- included BFQ IO Scheduler for 4.4 kernels
- USB Fastcharge
- Various CAF improvements
- upstream patches from kernel/common
- Locking Backports from 4.9 Kernel
- OOM_Reaper, OOM_Kill Backport from 4.9 kernel
- Lowmemorykiller Backport from 4.9 Kernel
- RCU backport from 4.9 kernel
Instructions:
1. Please dirty flash your rom to have a clean ramdisk
2. Backup your current setup in twrp
3. flash the zip file/s according to your favorite install method in twrp
4. reboot
5. If you dont want to use @tbalden ´s rootless kernel apps, but traditional root via supersu or magisk delete the uci....cfg file from the root of your sdcard
6. Enjoy your phone
Download:
OREO: https://www.androidfilehost.com/?w=files&flid=251050
Nougat: https://www.androidfilehost.com/?w=files&flid=229307
Changelog:
1.003:
https://forum.xda-developers.com/showpost.php?p=73283377&postcount=174
https://forum.xda-developers.com/showpost.php?p=73283388&postcount=175
ZERO_BETA_2
https://forum.xda-developers.com/showpost.php?p=73500972&postcount=233
ZERO_GAMMA_4
https://forum.xda-developers.com/showpost.php?p=73533313&postcount=296
ZERO_GAMMA_6
2.0
https://forum.xda-developers.com/showpost.php?p=73806358&postcount=386
3.0
https://forum.xda-developers.com/showpost.php?p=73874622&postcount=424
CAF_1.0
https://forum.xda-developers.com/showpost.php?p=73983865&postcount=493
CAF 1.10
https://forum.xda-developers.com/showpost.php?p=74055104&postcount=626
CAF 1.20
https://forum.xda-developers.com/showpost.php?p=74103333&postcount=676
CAF 1.30
https://forum.xda-developers.com/showpost.php?p=74135102&postcount=687
CAF 1.31
https://forum.xda-developers.com/showpost.php?p=74163796&postcount=703
CAF 2.00
https://forum.xda-developers.com/showpost.php?p=74202067&postcount=719
CAF 2.10
https://forum.xda-developers.com/showpost.php?p=74270321&postcount=755
CAF 3.0
https://forum.xda-developers.com/showpost.php?p=74476266&postcount=792
CAF 3.1
https://forum.xda-developers.com/showpost.php?p=74677436&postcount=845
OREO 1.0
https://forum.xda-developers.com/showpost.php?p=75636045&postcount=918
OREO 1.3
https://forum.xda-developers.com/showpost.php?p=75675979&postcount=938
OREO 2.0
https://forum.xda-developers.com/showpost.php?p=75843285&postcount=955
OREO 4.0
https://forum.xda-developers.com/showpost.php?p=76020308&postcount=987
OREO 5.0
https://forum.xda-developers.com/showpost.php?p=76287809&postcount=1029
OREO 7.0
https://forum.xda-developers.com/showpost.php?p=76625681&postcount=1053
OREO 10.0
https://forum.xda-developers.com/showpost.php?p=77187817&postcount=1082
OREO 11.0
https://forum.xda-developers.com/showpost.php?p=77588328&postcount=1107
OREO 12.0
https://forum.xda-developers.com/showpost.php?p=77757572&postcount=1113
OREO 13.1
https://forum.xda-developers.com/showpost.php?p=78144426&postcount=1146
OREO 15.0
https://forum.xda-developers.com/showpost.php?p=78815371&postcount=1170
Credits and Thanks:
I want to say thank you to all those who helped me along my way, who answered all my questions and took their time to support me. Huge thanks to @tbalden @Eliminater74 @Captain_Throwback @RenderBroken
Additionally a huge thanks to @RenderBroken for doing the main work on getting EAS on the android 4.4 kernel. Without him this wouldn´t exist. Drop him a thanks on his threads or show your appreciation with a little donation.
This credit also goes out to @joshuous who works together with @RenderBroken.
Credits:
@flar2 for his complete work
@tbalden for his led tricks, adreno boost etc
@Flinny for helping me with compiling the kernel!
@savoca for Kcal
@Eliminater74 for bringing me into the kernel game
@Sultanxda
@eng.stk
@osmosis
@frap129
@velimirchek for all the testing and support
@tomascus for the nougat base!!
@jsaxon2 for helping me with the OREO magisk module!
and all others that helped me on my way
also for the OREO Kernel Testers!
@zhuchella
@aadeshiscool
@Snah001
@ffh2303
@cjrivera04
@Derepinar
@p50kombi
@CharliesTheMan
@jsaxon2
Donations:
Donations are not mandatory but very welcome..
If you like my work: http://paypal.me/freak07
Source: https://github.com/freak07/OCEAN_OREO_EAS
So this post will be dedicated to information about EAS in general.
Here is a good breakdown on EAS vs traditional HMP (which the other kernels here are using)
Right here we go.
EAS is a completely different breed compared to the conventional HMP system, where it serves an entirely different purpose of achieving the optimal balance between performance and efficiency, with the latter taking the top spot. EAS achieves that via cleverer tasks placement, by which the system determines which is the more efficient cluster for the task to be processed by, as well as categorising the different tasks into cgroups (top-app, foreground and background, in order from highest priority to lowest priority respectively) by which each cgroup receives its sliver of the available firepower (cpuset). EAS also offers the capability of inflating the perceived load, that's determined by the load trackers, of the task in any of the cgroups via its schedtune.boost setting, and whether the task should be processed by all the cpu cores available or only by the cluster the task has been placed on via its schedtune.prefer_idle setting. One of the key features of EAS is lifting almost all the processing from the governor to the CPU scheduler (no it is not the I/O scheduler, something different) and letting it take much much more control, leaving the CPU governor to only do the frequency determination part, which unsurprisingly relies heavily on data supplied by the scheduler. With all that said, it is easily deduced that EAS is not all about governors and governor settings and the like, rather a much cleverer solution that serves the purpose of seeking the best balance between performance and efficiency, and to ensure the CPU is not overdoing a task or the CPU governor is overshooting a simple task, which would attribute to needlessly draining a lot of power as a natural consequence. EAS is about ensuring you get the smoothest UI possible while retaining as much power as possible. However, that does not mean that EAS is lame poor when it comes to performance. Sometimes, if not in most cases, this cleverer tasks placement makes tasks get processed faster, a point that is already proved quite well by the EAS-supporting non-OOS based custom ROMs like VertexOS, ZeNiTy-RR and PAEX. Conserving battery does not necessarily mean crushing performance. This explains that app launches are on-par with HMP if not ahead of it sometimes.
Now on to your question. After going through that brief explanation of EAS, i think your question is actually invalid, since it is not an apple-to-apple comparison anymore. EAS seeks for the optimal balance between performance and efficiency. Should there be a commit to improve performance while not being at the expense of efficiency, EAS should have that stuffed in, whereas HMP is prioritising performance higher than efficiency by design. What Burnout does is taking HMP and making it even more performance oriented, hence it is very unlikely to face micro lags with it. However, HMP still misses the cleverer tasks placement, which can show its canines if you have so much processes going in the background, where in that area EAS takes the lead quite noticeably.
Conclusion: You should try and see what suits you more. But something i can safely say is, EAS is more than satisfactory when it comes to performance from the perspective of a man that always seeks the best performance available, and with the battery gains you yield with EAS, it can go better.
Hope i helped and clear the confusion.
-TDK
A short Explanation on WALT vs PELT. This kernel uses WALT.
RenderBroken said:
An amazing write up by a talented dev @joshuous:
PELT and WALT
Time for me to flex the analogy muscles.
Just to set things straight, PELT and WALT are different load tracking metrics that try to determine the load of the system. The load will eventually be used by the frequency governor to set the frequency. Think of them (the load tracking metrics) as an employee who is dedicated to announcing how quickly customers are coming into your burger restaurant. The frequency governor is the burger chef, who isn't able to see the number of customers entering, so he has to rely on the announcer in order to know the rate at which he is making burgers. The announcer can say that there are "many" customers, and the chef has to decide how fast to make the burgers based on how he interprets "many".
One announcer can say that 10 customers is "many", while another may say that 20 is "many". An announcer may also attempt to predict the number of customers that will enter based on how many he sees at the current point in time. In this way, burger output is more 'bursty'. For example, there are 10 customers ("many"), then no customers ("none"), then 15 customers ("very many"). The chef works hard, then thinks he can take a break for a moment, then suddenly has to work like crazy to dish out burgers for 15 customers. An oversimplified analogy to WALT.
On the other hand, another announcer may observe a trend of customers and apply some prediction to guess how many customers might come through the door. Using the same customer sequence as before, he may instead tell the chef "many", "some", then "many". So the chef may make burgers even when there are no customers, in anticipation of future customers, but he won't be worked so darn hard all of a sudden. This is less bursty and more consistent. An oversimplified analogy to PELT.
In the same way there are different chefs (e.g. Sched and Schedutil). They have different interpretations of what "many" means to them. That's why their burger outputs may be different even when having the same announcer.
So which is better? It all boils down to your workload, and even so it is difficult to make a conclusion. All I can say is that you must test each mechanism for over a week and check your active drain rate (Ex Kernel Manager is good for this). Active drain rate is a much better measure than SOT. And make sure to keep jumping back and forth between the two to account for anomalies.
Edit: On another note, to complete the analogy... Interactive and HMP is more similar to the chef being the announcer as well. Except for he is able to see less than a dedicated announcer can. I.e the chef (interactive governor) can't look at the queue outside his restaurant but only the ones in his restaurant (so he is partly blind). A dedicated announcer can look at customers inside and outside the restaurant though.
Do note that this has little to do with EAS per se. EAS is a different beast that focuses on optimizing which customers is assigned to which chefs. I'll probably write the analogy for this another time if there is a demand for it
Click to expand...
Click to collapse
FAQ
Q: I got the SD is corrupted message after booting and my sdcard is formatted as exfat. What should I do?
A: Reboot to Recovery mount USB storage, unmount it and reboot.
Q: I switched kernels and now my wlan isn´t working?
A: that is because I have to use my own wlan module. restore system of your nandroid. or extract stock wlan module from custom rom.
Q: My device does not sleep and the reason is media scanner is holding the device awake. What to do?
A: There can be a strange case where the exfat nofuse driver I have to use in order for external sdcard to work creates an infinite folder loop.
It can be solved if you check your sdcard with a file manager for a folder like android/data/com.xyz.app/files/files/files/files...... and so on.
Go to twrp recovery move the infinite file folder to the root of external sdcard. Then it can be easily deleted. Before moving the file deleting it is not possible.
Q: How to set up the cleanslate LED/Notification Light/BLN options?
A: Take a look at this post: https://forum.xda-developers.com/showpost.php?p=72710244&postcount=2
Not needed as per Version 3.0
Q: Netflix isn´t playing videos?
A: go to settings -> dev options -> untick disable hw overlays, watch netflix and don´t forgot to tick the option again after using netflix ( say thank you to HTC for not releasing the new source)
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 @joshuous
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 @Mostafa Wael and @joshuous
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 @joshuous
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://forum.xda-developers.com/showpost.php?p=74054394&postcount=526
Proper Way to Report a Bug
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
4
ramopps: Some Documentation on Ramopps
Normal Logcat:
Code:
adb logcat -v time -d > logcat.log
Radio Logcat:
Code:
adb logcat -b radio -v time -d > logcat_radio.log
Ramoops:
Code:
adb shell su -c cat /sys/fs/pstore/console-ramoops > kmsg.txt
Kernel Log:
Code:
adb shell su -c dmesg > dmesg.log
Last_Kmsg: NOTE:
New location of last_kmsg on Android 6.0 and above: /sys/fs/pstore/console-ramoops
Code:
adb shell su -c "cat /proc/last_kmsg" > last_kmsg.log
NOTES:
-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
URL: http://forum.xda-developers.com/showthread.php?t=2185929
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..
[DMESG Help Commands]
Code:
Usage:
dmesg [options]
Display or control the kernel ring buffer.
Options:
-C, --clear clear the kernel ring buffer
-c, --read-clear read and clear all messages
-D, --console-off disable printing messages to console
-E, --console-on enable printing messages to console
-F, --file <file> use the file instead of the kernel log buffer
-f, --facility <list> restrict output to defined facilities
-H, --human human readable output
-k, --kernel display kernel messages
-L, --color[=<when>] colorize messages (auto, always or never)
colors are enabled by default
-l, --level <list> restrict output to defined levels
-n, --console-level <level> set level of messages printed to console
-P, --nopager do not pipe output into a pager
-r, --raw print the raw message buffer
-S, --syslog force to use syslog(2) rather than /dev/kmsg
-s, --buffer-size <size> buffer size to query the kernel ring buffer
-u, --userspace display userspace messages
-w, --follow wait for new messages
-x, --decode decode facility and level to readable string
-d, --show-delta show time delta between printed messages
-e, --reltime show local time and time delta in readable format
-T, --ctime show human readable timestamp (may be inaccurate!)
-t, --notime don't print messages timestamp
--time-format <format> show time stamp using format:
[delta|reltime|ctime|notime|iso]
Suspending/resume will make ctime and iso timestamps inaccurate.
-h, --help display this help and exit
-V, --version output version information and exit
Supported log facilities:
kern - kernel messages
user - random user-level messages
mail - mail system
daemon - system daemons
auth - security/authorization messages
syslog - messages generated internally by syslogd
lpr - line printer subsystem
news - network news subsystem
Supported log levels (priorities):
emerg - system is unusable
alert - action must be taken immediately
crit - critical conditions
err - error conditions
warn - warning conditions
notice - normal but significant condition
info - informational
debug - debug-level messages
[LOGCAT Help Commands]
Code:
Usage: logcat [options] [filterspecs]
options include:
-s Set default filter to silent.
Like specifying filterspec '*:S'
-f <filename> Log to file. Default is stdout
-r <kbytes> Rotate log every kbytes. Requires -f
-n <count> Sets max number of rotated logs to <count>, default 4
-v <format> Sets the log print format, where <format> is:
brief color long printable process raw tag thread
threadtime time usec
-D print dividers between each log buffer
-c clear (flush) the entire log and exit
-d dump the log and then exit (don't block)
-t <count> print only the most recent <count> lines (implies -d)
-t '<time>' print most recent lines since specified time (implies -d)
-T <count> print only the most recent <count> lines (does not imply -d)
-T '<time>' print most recent lines since specified time (not imply -d)
count is pure numerical, time is 'MM-DD hh:mm:ss.mmm'
-g get the size of the log's ring buffer and exit
-L dump logs from prior to last reboot
-b <buffer> Request alternate ring buffer, 'main', 'system', 'radio',
'events', 'crash' or 'all'. Multiple -b parameters are
allowed and results are interleaved. The default is
-b main -b system -b crash.
-B output the log in binary.
-S output statistics.
-G <size> set size of log ring buffer, may suffix with K or M.
-p print prune white and ~black list. Service is specified as
UID, UID/PID or /PID. Weighed for quicker pruning if prefix
with ~, otherwise weighed for longevity if unadorned. All
other pruning activity is oldest first. Special case ~!
represents an automatic quicker pruning for the noisiest
UID as determined by the current statistics.
-P '<list> ...' set prune white and ~black list, using same format as
printed above. Must be quoted.
filterspecs are a series of
<tag>[:priority]
where <tag> is a log component tag (or * for all) and priority is:
V Verbose (default for <tag>)
D Debug (default for '*')
I Info
W Warn
E Error
F Fatal
S Silent (suppress all output)
'*' by itself means '*:D' and <tag> by itself means <tag>:V.
If no '*' filterspec or -s on command line, all filter defaults to '*:V'.
eg: '*:S <tag>' prints only <tag>, '<tag>:S' suppresses all <tag> log messages.
If not specified on the command line, filterspec is set from ANDROID_LOG_TAGS.
If not specified with -v on command line, format is set from ANDROID_PRINTF_LOG
or defaults to "threadtime"
[/QUOTE]
That's great achievement, congrats and thanks for bringing eas to the u11!
congrats!
Also @damanrico this might interest you. For me every lag the u11 with the stock hmp implementation had is eliminated with EAS.
To everyone.
Just set input boost to 1,401ghz for the small cluster in ex kernel manager.
duration to 1500ms
And
dev/stune/top-app/schedtune.boost to 20
Edit:
dev/stune/schedtune.boost to 5
Please experiment with this settings. I want this completely smooth.
Make sure to use schedutil governor!
Freak07 said:
Also @damanrico this might interest you. For me every lag the u11 with the stock hmp implementation had is eliminated with EAS.
To everyone.
Just set input boost to 1,401ghz for the small cluster in ex kernel manager.
duration to 1500ms
And
dev/stune/top-app/schedtune.boost to 20
dev/stune/schedtune.boost to 5
Please experiment with this settings. I want this completely smooth.
Make sure to use schedutil governor!
Click to expand...
Click to collapse
For me it is smooth as baby a$$ in this short time I am using it ..
I'd like to try this...any chance for a Magisk-compatible version? I don't ever write directly to system anymore...
Flashed it and my wifi won`t turn on at all.
grega_slo said:
Flashed it and my wifi won`t turn in at all.
Click to expand...
Click to collapse
Are you on magisk?
Nope.
Latest Viper coming from elemetalx kernel.
grega_slo said:
Flashed it and my wifi won`t turn on at all.
Click to expand...
Click to collapse
Freak07 said:
Are you on magisk?
Click to expand...
Click to collapse
Same here, wifi not turning on. I'm on US Unlocked 1.16 firmware running magisk version of Viper rom 1.5
I'll see if I can grab log files later today, but I'm at work now.
grega_slo said:
Nope.
Latest Viper coming from elemetalx kernel.
Click to expand...
Click to collapse
Can you extract the file qca_cld3_wlan.ko out of the directory /system/lib/modules/qca_cld3 from my Zip
And push it to /system/lib/modules/qca_cld3
overwrite the existing module, set permissions to 644 rw-r--r-- and reboot?
And see if that fixes it?
What version of the phone do you have?
jsaxon2 said:
Same here, wifi not turning on. I'm on US Unlocked 1.16 firmware running magisk version of Viper rom 1.5
I'll see if I can grab log files later today, but I'm at work now.
Click to expand...
Click to collapse
Would you also try this?
Can you extract the file qca_cld3_wlan.ko out of the directory /system/lib/modules/qca_cld3 from my Zip
And push it to /system/lib/modules/qca_cld3
overwrite the existing module, set permissions to 644 rw-r--r-- and reboot?
And see if that fixes it?
What version of the phone do you have?
Freak07 said:
Would you also try this?
Can you extract the file qca_cld3_wlan.ko out of the directory /system/lib/modules/qca_cld3 from my Zip
And push it to /system/lib/modules/qca_cld3
overwrite the existing module, set permissions to 644 rw-r--r-- and reboot?
And see if that fixes it?
What version of the phone do you have?
Click to expand...
Click to collapse
just did that and it worked
Edit: European dual sim
velimirchek said:
just did that and it worked
Click to expand...
Click to collapse
Yup +1
Thank you both. Did a silly mistake. Will upload new zip soon. The wlan module didn’t get flashed.
Freak07 said:
Thank you both. Did a silly mistake. Will upload new zip soon. The wlan module didn’t get flashed.
Click to expand...
Click to collapse
FYI I made a Magisk version of the zip that doesn't flash anything to system and a separate Magisk support module, and it seems to be working okay (I have working Wi-Fi, if that's any indication). Is there any way for me to know for sure that everything is working as it should?