Related
Changelog
Notes on the new interactive governor below.
04/25/13
interactive governor updates from Tinykernel (Galaxy Nexus)
new sysfs path for fast charge - still compatible with incredicontrol
additional TCP congestion scheduler options with a default scheduler of cubic
10/04/12
New interactive governor backported from Incredikernel GB. Smartassv2 still default
Removed rarely used CPU governors
08/10/12
added mamarley's fastcharge USB patch to enable fastcharge without needing to unplug the charger
enabled KSM (Kernel Samepage Merging) - no change needed to make it active
03/11/12
Added Lazy governor - credit to Ezekeel
Enabled Smartass and Conservative governors
02/25/12
Disabled smartass,interactive,conservative governors
Disabled CFQ and BFQ governors as they were found not to be a efficient on flash devices
New I/O scheduler - SIO
New CPU governor - lagfree
smartassV2 is default governor again
Tweaked deadline scheduler for performance
Applied different zram patch, should be more stable, and removed memory tweaks in zram script (have to disable/enable to reset)
12/31/11
Patch kernel to 2.6.35.14
Tweak intellidemand and interactiveX governors for battery life
Ext4 patch for performance
Add ZRAM and swap support and add script to toggle ZRAM - see bottom of OP for more info
12/25/11
Increase min and max voltages by 25 for all non-OC frequencies
Added faux123′s intellidemand governor (thanks faux123!) - similar to ondemand but with screen off
Added imoseyon’s interactiveX governor (thanks imoseyon!) - interactive with screen off
12/01/11
Revert config setting that was causing freezing issues
Allow overvolting up to 1375 for more stability in overclocking
Revert default smartassv2 settings back to those of pre-11/6 kernel
Fix permissions on sysfs which were causing force closes in some apps
Use new ondemand,performance, and conservative governors
11/19/11
Tweak ondemand governor
Interactive governor fix
Update BFQ to v3-r1
Add and enable Tiny Preempt RCU (should perform even better than Tiny RCU)
11/10/11
Adjust smartassv2 scaling (see github for details)
Fix touchscreen issue that occurs on some devices
config: set tiny rcu (lower memory footprint)
add 1152000 and 1190400 CPU frequencies - only try if you're adventurous
various behind-the scenes fixes
11/06/11
Add interactive governor
Add smartass governor
Increase smartassv2 ideal wake frequency to 998Mhz - should help performance (if you don't like, underclock to 768 - this may change in a future release)
Add BFQ I/O Scheduler
HAVS+Sysfs interface (use Incredicontrol or boot scripts - see incredikernel.com and incredikernel thread for more information)
Fixed wifi not starting on certain ROMs such as McTwist - hopefully
11/02/11
Added unified panel driver from incredikernel and gingertiny-v1 for better responsiveness
Added msm_vibrator from gingertiny-v1 for smoother haptic feedback with smartass
Enabled TUN VPN support
10/31/11
Features:
Rebased on HTC official Incredible gingerbread .13 kernel
Audio Boost (Thanks Chad0989 for letting me use your source for this)
USB Fast Charging (Thanks Chad0989 for letting me use your source for this)
compressed kernel further for better support with boot manager
support for 128Mhz as well as overclock up to 1113
3/5 point multitouch support on supported devices
lowered wifi voltage
OC up to 1.113Ghz
Built in modules for cifs, smartassv2, conservative, ext4, ntfs (read only)
HTC's perflock removed
Ext4 driver used to mount ext2/3 filesystems (default in cyanogenmod and incredikernel)
Enabled swap support (need app like swapper from market to utilize)
SD Card and EMMC mount should work properly on all Sense ROMs now.
incorporated some tweaks from incredikernel
support for wifi-n (2.4ghz only - hardware limitation)
Audio Boost and USB fast charging are disabled by default in this version (I don't like audio boost). You can enable audio boost in the same way you enable USB fast charge.
10/23/11
Ext4 driver used to mount ext2/3 filesystems (default in cyanogenmod and incredikernel)
Updated to new OJ driver from Cyanogenmod kernel
[*]Sysfs interface for SVS (can now use incredicontrol) Not working properly
10/15/11
Fixed G-sensor issue (calibration, 3d-home screen, auto-rotate should work now)
10/08/11
Adjusted smartassV2 parameters for better performance
10/05/11
Set smatassV2 as default governor
incorporated some tweaks from incredikernel
added support for wifi-n (2.4ghz only - hardware limitation)
09/29/11
Added smartassV2 (erasmux)
09/20/11
Tweaked smartass governor to resolve reboot issues reported with using smartass (please let me know - it seems better for me so far)
Enabled swap support (need app like swapper from market to utilize)
Enabled compcache support (if ROM has uitility installed I can work on a script, currently I can't get the utility to work)
09/01/11
set max speed to 998 as phone would overclock at boot regardless of setcpu/overclocking app's setting which caused bootloops for phones that couldn't handle overclocking (Thanks Chad for the tip!)
08/31/11
Initial Release
Audio Boost (Thanks Chad0989 for letting me use your source for this)
USB Fast Charging (Thanks Chad0989 for letting me use your source for this)
compressed kernel further for better support with boot manager
support for 128Mhz as well as overclock up to 1113
3/5 point multitouch support on supported devices
lowered wifi voltage
OC up to 1.113Ghz
Built in modules for cifs, smartass, tun, conservative, powersave, ext4
HTC's perflock removed
Bootup frequency increased to 998
Known issues:
Beats will not work. This is not a specific issue with this kernel but rather that the support is not built into the stock kernel. It worked in the port but I'm not sure what needs to be changed.
Incredicontrol force closes when trying to open the HAVS tab. This only seems to happen at boot and clears up. Since it clears up on it's own, I don't think it's a kernel issue though but I'm leaving it on here so people are aware.
*Disclaimer*
Please do not report bugs if you overclock or undervolt/overvolt differently than what is set by default. It adds too many variables. Set CPU max back to 998 and report a bug then if it doesn't go away after that.
I am not supporting the older .10 kernels at this time though if you decide to still use it I may need your assistance to get Beats audio working.
*Note*
1. Just because it's been asked before about what ROMs this kernel supports, this kernel does not need to be built to support any particular ROM but is confirmed to be working fine on many of the most popular Gingerbread Sense ROM by multiple users and several leading devs. If it does not work on your ROM let the dev know first in case it's a known issue.
2. Smartass (v1 and v2) has a built in min speed of 245 and will go to the set min speed only when the screen is off. Due to the nature of the governor, don't use a screen off profile with Smartass. It has been reported to cause issues. If you want a screen off profile use a different governor.
OC voltages are set to the same as 998 Mhz. Sense is a tricky animal when it comes to voltage adjustments. I had about 10x the issues with undervolting on sense froyo as on aosp, but maybe it's because that kernel was undervolted more.
*Important*
If you get random reboots or freezes on the new kernels (10/31 or 11/2), I will need the logs of that:
If it's a reboot grab the file /proc/last_kmsg using adb or root explorer. For adb setup please do a search on xda or the internet.
It would be adb pull /proc/last_kmsg for the adb command.
For root explorer just copy to the sdcard. It's a text file so you can post it online and post the link here or attach to your post when you report the issue.
If it is a freeze try to use logcat and output to a file when you're trying to reproduce it. Google logcat usage if needed. Also grab the last_kmsg after rebooting.
Release kernel found at
incredikernel.com
Update: 11/15/12 - I've added a mirror for my files on goo.
http://goo.im/devs/tiny4579/inc/kernels
Source Code(Dev Only, not flashable)
Github.com Kernel Source
All releases are built from the master branch.
The config for the kernel is in arch/arm/configs/incrediblec_defconfig.
I use the GCC 4.4.3 toolchain for this kernel due to GCC 4.6 causing build issues.
Below is a link to the original tiny-gingersense source which is a hybrid kernel running off code released for the Evo Sense kernel as well as some code from the Froyo Incredible sense kernel. This one uses the master branch as well and the same config filename and toolchain as v2.
Original tiny-gingersense kernel source
Frequently Asked Questions:
Some key differences between smartass and smartassv2 so users can decide which they prefer and learn a bit more about the differences:
Smartass
1. Screen off profile built in maxed at 384mhz.
2. Wakeup frequency is 998mhz.
3. Min screen on is 245mhz.
4. Improved by Chad to run better on our devices.
5. Purely load based, no ideal value.
Smartassv2
1. This is the same exact governor in Erasmux's Nexus One kernel (github.com/erasmux/n1-kernel)
2. Ideal wake frequency is 768 (also default that can be changed).
3. Screen on min is actually 128mhz).
4. No screen off profile.
5. Ideal sleep frequency 245mhz.
6. Improved upon from erasmux's version, not Chad's.
Basically the smartassv2 ideal wake frequency allows the phone to favor a certain speed to attempt to save battery life. It can still go above ideal wake and below ideal sleep so there's no caps on max and min while awake or sleep.
Some tips/info on various governors:
Smartass/smartassv2/interactive:
Use 128 min so the governor can scale as it needs to. Max speed I'd recommend at least 768Mhz.
Ondemand:
Try 128 min and if it lags use 245 min. Max speed I'd recommend at least 768Mhz.
Performance:
Only recommended for benchmarks but speed will always run at max.
InteractiveX:
Same as interactive except it has an auto screen off set to the min. Ideal with 245 min in setcpu but try 128 for battery life but it you have wake lag then set to 245.
Intellidemand:
Based on ondemand with a built in screen off. Any speed settings should be fine.
Interactive:
Some new features with this one. Starting with 10/4/12 release I am using the interactive kernel from Google which features a new kernel option called input_boost.
It is off by default but can be enabled by writing a 1 to /sys/devices/system/cpu/cpufreq/interactive/input_boost. Also there is another parameter for interactive called hispeed_freq in the same location. The hispeed_freq is where the governor jumps to first. Hispeed_freq by default is 614400 to help save battery. In the older interactive governor there was a maxspeed freq which meant the governor was a bit jumpier to the max speed. This should be a good blend of performance and battery.
ZRAM, what is it and how to I add it? (starting officially with 12/31/11)
If you are familiar with swap space in linux or virtual memory in Windows it is a similar concept. Except instead of using the hard drive as swap space it compresses swap space in RAM for faster access times than conventional swap. This will also wear out our storage memory less than typical swapping.
Enable ZRAM is simple thanks to a script built by imoseyon which is provided in the kernel zip file. To enable, use adb shell or download a terminal app and run zram enable. This will persist across reboots (if init.d is setup in your ROM) so if you don't want it anymore run zram disable and it will remove the bootscript and deactivate it.
You need to have root privileges to enable/disable zram. Run the su command in terminal emulator to request root.
Way to go! But I bet this was a headache to put together.
Let me know if you need a beta tester and the slots haven't filled up.
godsmacked4653 said:
Way to go! But I bet this was a headache to put together.
Let me know if you need a beta tester and the slots haven't filled up.
Click to expand...
Click to collapse
Check your PM.
Is this the beginning of a whole slew of custom kernels for the inc ?
How is the battery life on this?
i can test if needed
Exciting stuff...
any idea or have you looked at how difficult it would be to enable 5 pt multi touch in the future? or GPU+?
Hit me up... I'd love to test.
Love to test. Would begging help. Lol
Sent from my ADR6300 using Tapatalk
Ok, got the 5 testers I want. Actually I found 6 so I'm good for now.
tiny4579 said:
Hi all!
Good news! I have successfully initially ported the HTC Incredible kernel to gingersense using the Evo gingerbread source as a base and pulling from the Inc's froyo source code. I have spent significant time over the past few weekends trying to get this work and I have something usable finally. (I never ported a kernel before but am satisfied with what I have here).
Thanks Chad for inspiring me to do this port and giving me pointers along the way!
What works:
1. 3g+wifi
2. all modules from modules thread are built in+cifs added as well (perflock_disable is not needed on this kernel)
3. camera - initially had trouble, it wouldn't boot with camera enabled. 720p video SHOULD work as well
4. artifacting issues should be resolved
5. overclock works (1.13Ghz)
I would like to have some testers prior to releasing it as open beta. I want 4 additional testers, have 1 already. The first 4 to volunteer to test (via PM or this thread) will get a PM with a link to test the kernel. It will flash like any other kernel. I would like to post tomorrow night so please give feedback.
Known issues:
May be overheating issues. Though I cannot confirm issue. Battery temp is fine for me.
It is a port. Not everything will necessarily work 100%.
Haptic feedback and vibration are currently broken. Will look into it.
Github.com Kernel Source
Click to expand...
Click to collapse
try changing the inc-kepad.kl to incrediblec-keypad.kl in the /usr folder of the rom
Damn...
Sent from my ADR6300 using xda premium
And amazing work man!!
runs nice so far...
i do miss haptic
JoelZ9614 said:
try changing the inc-kepad.kl to incrediblec-keypad.kl in the /usr folder of the rom
Click to expand...
Click to collapse
Tried it but no go. Thanks for trying to assist me though.
Checked up on GPU+. It is not needed as the changes needed to implement it have already been done in the stock HTC kernel.
5-point multitouch will be tricky as my panel has never worked with more than 2. I remember Chad trying to get it to work for everyone but it was tricky even for him. I think certain phones will just not work with it. I can see if I can at least enable it and have others test. If you're going to test, make sure that it works currently on say a Froyo Sense ROM or your AOSP ROM of choice first.
Going to bed so no more requests tonight.
Ran through some quick tests and everything looks to be working, and working well. I'm running godsmacked's senseless 2.0 with lp+. Gps locks on quick. Camera, gallery, etc all good. Overclocking stable so far, and definitely makes a notable difference. I will do more in depth testing tomorrow. Thanks for the breakthrough!
baboonsRus said:
Ran through some quick tests and everything looks to be working, and working well. I'm running godsmacked's senseless 2.0 with lp+. Gps locks on quick. Camera, gallery, etc all good. Overclocking stable so far, and definitely makes a notable difference. I will do more in depth testing tomorrow. Thanks for the breakthrough!
Click to expand...
Click to collapse
Is your haptic feedback working with the kernel?
love to be a tester too.
Great job Tiny!! This had to be very difficult to port. Your work is much appreciated.
Tiny, I PMd you about the vibrator, should be an easy fix.
And I would also like to commend tiny for doing the work on this. It has lifted a bit of a burden off of my shoulders since I simply didn't have the time to put work into it myself. He's quite adept and problem solving and was able to continue when he ran into a problem with just a little bit of guidance. I trust that he will put out a good kernel.
Team-M8 AOSP kernel
What is it?
This project was initially based on Unicornblood kernel from DirtyUnicorns (@smac0628), which is current with linux 3.4.110. She and I are working together on this project to make a better experience for users.
We aim to include as many tweaks as possible to this AOSP kernel while maintaining stability. We also make extensive efforts to properly give credit the authors of the many features we've added (picked only the original author's commits, instead of kanging entire files).
Settings have intentionally been chosen which favor battery life over performance. With that said, you can definitely squeak out a little better battery life, or you can have some fun and get killer performance instead.
Features:
Hotplugs (only enable one!, more on the way):
IntelliPlug
Great balance between battery life and performance. It is also a popular hotplug driver from faux123.
MSM Hotplug
Great battery life, a custom qualcomm based hotplugging driver by myflux. It is a popular choice for many users.
Alucard Hotplug
A great hotplugging driver by Alucard. It is known to be very battery friendly on devices.
Zen Decision
ZEN only onlines all cores when screen is on, it also takes thermal events into account and wont online any core back, if you're under 15% battery, or currently have a thermal event because of heat. So in the end it isn't a "real" hotplug driver, because it doesnt have any code for active hot plugging in it. That means you can't change its behavior.
Hybrid Hotplug/Governor (Disable all hotplugs if you're going to use this)
zzmoove
The ZZmoove Governor by ZaneZam is optimized for low power consumption when the screen off, with particular attention to the limitation of consumption applications in the background with the screen off, such as listening to music. The unique feature with ZZmoove is that it has predefined profiles and allows profile switching. This governor is still a WIP as the developer is constantly giving updates! Here are the available profiles:
Quote:
1) for Default (set governor defaults)
2) for Yank Battery -> old untouched setting (a very good battery/performance balanced setting DEV-NOTE: highly recommended!)
3) for Yank Battery Extreme -> old untouched setting (like yank battery but focus on battery saving)
4) for ZaneZam Battery -> old untouched setting (a more 'harsh' setting strictly focused on battery saving DEV-NOTE: might give some lags!)
5) for ZaneZam Battery Plus -> NEW! reworked 'faster' battery setting (DEV-NOTE: recommended too! )
6) for ZaneZam Optimized -> old untouched setting (balanced setting with no focus in any direction DEV-NOTE: relict from back in the days, even though some people still like it!)
7) for ZaneZam Moderate -> NEW! setting based on 'zzopt' which has mainly (but not strictly only!) 2 cores online
8) for ZaneZam Performance -> old untouched setting (all you can get from zzmoove in terms of performance but still has the fast down scaling/hotplugging behaving)
9) for ZaneZam InZane -> NEW! based on performance with new auto fast scaling active. a new experience!
10) for ZaneZam Gaming -> NEW! based on performance with new scaling block enabled to avoid cpu overheating during gameplay
11) for ZaneZam Relax -> NEW! based on moderate (except hotplug settings) with relaxed sleep settings
(since version 0.9 beta4: cpu temperature threshold of 65°C enabled if exynos4 cpu temperature reading support was compiled with the governor)
Click to expand...
Click to collapse
CPU Governors (more on the way):
A CPU governor in Android controls how the CPU raises and lowers its frequency in response to the demands the user is placing on their device. Governors are especially important in smartphones and tablets because they have a large impact on the apparent fluidity of the interface and the battery life of the device over a charge.
Abyssplugv2
AbyssPlugv2 is a rewrite of the original CPU governor. It also fixes the problem where the governor is set only for the first core, but now governs all cores right from whatever utility you use. There have been comments on the lack of stability with this governor.
alucard
A favourite choice and one of the original governors that Alucard_24 made. Alucard is based on ondemand but has been heavily tweaked to bring better battery life and performance. It has been known to be battery friendly without sacrificing much performance.
badass
Badass removes all of this "fast peaking" to the max frequency. To trigger a frequency increase, the system must run a bit with high load, then the frequency is bumped. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)
Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu to max frequency, If the gpu is crushed under load, badass will lift the restrictions to the cpu
dancedance
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.
darkness
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
elementalx
If you are an owner of a nexus device, you probably have heard of a governor named ElementalX. Named after the kernel, elementalX is based on interactive but with some additional performance tweaks. This governor focuses on performance and not battery savings!
hellsactive
A heavily modified intelliactive governor by @hellsgod that has been tweaked to improve battery life. Hellsactive is less aggressive compared to intelliactive so the battery life will be more like the original interactive.
intelliactive
Based off Google's Interactive governor with the following enhancements:
1. self-boost capability from input drivers (no need for PowerHAL assist)
2. two phase scheduling (idle/busy phases to prevent from jumping directly to max freq
3. Checks for offline cpus and short circuits some unnecessary checks to improve code execution paths. Therefore, it avoids CPU hotplugging.
This is a more performance oriented CPU governor that still has great battery life like the original Interactive.
intellidemand
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode.
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) by behaving like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
intellimm
A rewrite of the old Min Max governor and has 3 cpu states: Idle, UI and Max. Intelliminmax (intellimm) governor is designed to work with the newer SOCs with fixed voltage rails (ie MSM8974+ SOCs). It is designed to work within those fixed voltage ranges in order to maximize battery performance while creating a smooth UI operations. It is battery friendly and spends most of the time at lower frequencies.
nightmare
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.
ondemand
Ondemand is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold, the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google's Interactive governor.
smartmax
Ondemand is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold, the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google's Interactive governor.
yankactive
A slightly modified interactive based governor by Yank555.lu. It has battery tweaks added onto it so expect better battery life! Based on user reports, this governor behaves more battery friendly than the original interactive governor without sacrificing performance.
yankdemand
Full stock (JB) ondemand governor with changed default tunable values aimed at lower battery consumption
interactive
Google's own take on a CPU governor. Interactive scales the clockspeed over the course of a timer set by the kernel developer (or user). In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. It is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
Interactive is the default governor of choice for today's smartphone and tablet manufacturers.
performance
The performance governor locks the phone's CPU at maximum frequency.
The descriptions in this post were created by @gsstudios and can be found here:
http://forum.xda-developers.com/general/general/ref-to-date-guide-cpu-governors-o-t3048957
Voltage Control (UV/OV)
OC to 2880 MHz
UC to 268 MHz
Set Max frequency in Screen-Off state
As the name says, you get to set a different governer when screen is off. This will override what you chose in the governer choice. Pretty nifty arrangement so that you can flip from a performance governer when on screen and a power save governer when screen is off. This feature was added to the kernel because it was either the developers intention or by popular demand.
Force Fastcharge
A. When set, the phone will charge off of the PC USB ports as if it is connected to wall outlet. This does turn off your access to the phone internal memory and SD card. If you want to access the internal storage on PC then you have to turn this off.
NOTE – Weather to turn on or off, has to be done before connecting to PC. Changing this after connecting has no effect.
Kexec hardboot patch (can be flashed as primary bootimage in multirom)
GPU Governors:
cpubw_hwmon
A hardware (HW) monitor based governor that attempts to determine bandwidth needed by CPU and other hardware. This is a unique GPU governor that is highly customisable, however it is known to be unstable on some devices.
msm_cpufreq
The MSM CPUfreq governor determines the CPU to DDR bandwidth vote based on the current CPU frequency of all the active CPUs. In other words, this governor scales based on CPU usage which could mean more performance.
msm-adreno-tz
The default GPU governor used by qualcomm for their adreno GPUs. It is more performance orientated than ondemand therefore it gives better performance in games but less battery life.
userspace
This governor basically allows the user is able to set a desired frequency for the GPU to run at.
powersave
Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.
performance
As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don't care about your battery life.
simple_ondemand
KCal display adjustments
IO Schedulers:
Input/output (I/O) scheduling is a term used to describe the method computer operating systems decide the order that block I/O operations will be submitted to storage volumes. I/O Scheduling is sometimes called 'disk scheduling'.
I/O schedulers can have many purposes depending on the goal of the I/O scheduler, some common goals are:
- To minimise time wasted by hard disk seeks.
- To prioritise a certain processes' I/O requests.
- To give a share of the disk bandwidth to each running process.
- To guarantee that certain requests will be issued before a particular deadline.
bfq
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
Benefits:
- Has a very good USB data transfer rate.
- The best scheduler for playback of HD video recording and video streaming (due to less jitter than CFQ Scheduler, and others)
- Regarded as a very precise working Scheduler
- Delivers 30% more throughput than CFQ
- Being constantly updated
- Good for multitasking, more responsive than CFQ
Disadvantages:
- Not the best scheduler for benchmarks
- Higher budgets that were allocated to a process that can affect the interactivity and bring with it increased latency.
cfq
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Benefits:
- Has a well balanced I / O performance
- Excellent on multiprocessor systems
- Regarded as a stable I/O scheduler
- Good for multitasking
Disadvantages:
- Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
- Jitter (worst case delay) can sometimes be very high because the number of competing with each other process tasks
- Under constant load, the phone will experience increased I / O latency due to the way how the scheduler tries to create 'fairness'
deadline
The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.
Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.
Benefits:
- Nearly a real-time scheduler.
- Excels in reducing latency of any given single I/O
- Best scheduler for database access and queries.
- Does quite well in benchmarks, most likely the best
- Like noop, a good scheduler for solid state/flash drives
Disadvantages:
- If the phone is overloaded, crashing or unexpected closure of processes can occur
fifo
First in First Out Scheduler. As the name says, it implements a simple priority method based on processing the requests as they come in.
Benefits:
- Serves I/O requests with least number of cpu cycles.
- Is suitable for flash drives because there is no search errors
- Good data throughput on db systems
Disadvantages:
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance
- Not very good at multitasking
fiops
This new I/O scheduler is designed around the following assumptions about Flash-based storage devices: no I/O seek time, read and write I/O cost is usually different from rotating media, time to make a request depends upon the request size, and high through-put and higher IOPS with low-latency. FIOPS (Fair IOPS) ioscheduler tries to fix the gaps in CFQ. It's IOPS based, so it only targets for drive without I/O seek. It's quite similar like CFQ, but the dispatch decision is made according to IOPS instead of slice.
Benefits:
- Achieves high read and write speeds in benchmarks
- Faster app launching time and overall UI experience
- Good battery life
Disadvantages:
- Not very common in most kernels
- Not the most responsive IO scheduler (Can make phone lag)
- Not good at heavy multitasking
noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Benefits:
- Serves I/O requests with least number of cpu cycles.
- Is suitable for flash drives because there is no search errors
- Good data throughput on db systems
- Good battery life
- Does great in benchmarks
- Also a very reliable IO scheduler
Disadvantages:
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance
- Not the most responsive I/O scheduler
- Not very good at multitasking (especially heavy workloads)
row
The ROW IO scheduler was developed with the mobile devices needs in mind. In mobile devices, we favor user experience upon everything else, thus we want to give READ IO requests as much priority as possible. In mobile devices we won't have as much parallel threads as on desktops. Usually it's a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly. The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much.
Benefits:
- Faster UI navigation and better overall phone experience
- Faster boot times and app launch times
Disadvantages:
- Not great for heavy multitasking
- Slower write speeds
sio
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Benefits:
- It is simple and stable.
- Minimized starvation for inquiries
- Good battery life
Disadvantages:
- Slow random write speeds on flash drives as opposed to other schedulers.
- Sequential read speeds on flash drives are not as good as other IO schedulers
tripndroid
A new I/O scheduler based on noop, deadline and vr and meant to have minimal overhead. Made by TripNRaVeR
Benefits:
- Great at IO performance and everyday multitasking
- Well rounded and efficient IO scheduler
- Very responsive I/O scheduler (Compared to FIOPS)
Disadvantages:
- Not found in all kernels
- Performance varies between different devices (Some devices perform really well)
vr
Unlike other scheduling software, synchronous and asynchronous requests are not handled separately, but it will impose a fair and balanced within this deadline requests, that the next request to be served is a function of distance from the last request.
Benefits:
- Generally excels in random writes.
Disadvantages:
- Performance variability can lead to different results (Only performs well sometimes)
- Sometimes unstable and unreliable
zen
ZEN scheduler is based on the VR Scheduler. It's an FCFS (First come, first serve) based algorithm, but it's not strictly FIFO. ZEN does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, it's pretty much the same as no-op blended with VR features.
Benefits:
- Well rounded IO Scheduler
- Very efficient IO Scheduler
- More stable than VR, more polished
Disadvantages:
- Performance variability can lead to different results (Only performs well sometimes)
- Not found in all kernels
LED Control
Z-Ram
Q. What is ZRAM?
A. ZRAM basically compresses unused apps within the system RAM. This allows the system to swap less needed processes to the zram partition for faster access at a later time, instead of killing them. This does take up some of your ram though, so I imagine that the value you are setting is determining exactly what percentage of your ram that the zram partition is allotted.
FSYNC
TCP Congestion Algorithms:
Congestion control strategies (or algorithms) are used by TCP, the data transmission protocol used by many Internet applications. The main goal of a TCP algorithm is to avoid sending more data than the network is capable of transmitting, that is, to avoid causing network congestion. Different algorithms respond differently to network loads, but they are all based on the same principle of avoiding network congestion.
Things to look out for in TCP algorithms include (but not exclusively):
- Download/Upload speeds - The higher the number, the better
- Latency - The lower the number, the better
bic
Binary Increase Congestion control (BIC):
BIC is optimized for high speed networks with high latency: so-called "long fat networks". It has a unique congestion window (cwnd) algorithm. This algorithm tries to find the maximum where to keep the window at for a long period of time, by using a binary search algorithm.
lp
Low Priority (LP):
A distributed algorithm whose goal is to utilize only the excess network bandwidth as compared to the "fair share" of bandwidth as targeted by TCP. The key mechanisms unique to TCP-LP congestion control are the use of one-way packet delays for early congestion indications and a TCP-transparent congestion avoidance policy.
highspeed
High speed (HSTCP):
High Speed TCP (HSTCP) is a new congestion control algorithm protocol for TCP. Standard TCP performs poorly in networks with a large bandwidth delay product. It is unable to fully utilize available bandwidth. HSTCP makes minor modifications to standard TCP's congestion control mechanism to overcome this limitation.
htcp
Hamilton TCP (HTCP):
HTCP is designed for high-speed, long distance networks that increases aggressiveness as the time since the previous loss increases. It is thought to be a more efficient TCP algorithm than BIC and HSTCP.
hybla
Hybla:
Penalizes connections that use satellite radio. Not usually used with phones.
illinois
Illinois is designed for high-speed, long-distance networks. A sender side modification to the standard TCP congestion control algorithm, it achieves a higher average throughput than the standard TCP and allocates the network resource fairly as the standard TCP.
scalable
Scalable calls for congestion window to be halved for each packet lost. Effectively, this process keeps halving the throughput until packet loss stops. Once the packet loss subsides, slow start kicks in to ramp the speed back up.
vegas
One of the smoothest TCP algorithms(next to cubic), it increases the timeout delay for packets, which allows more to be received, but at a higher rate. It also has set timeouts, which helps with speed because it's constantly being refreshed.
veno
Veno is closely related to Vegas, it is a combination of Vegas and Reno in order to enhance TCP performance over Wireless networks.
westwood
A newer version of Reno, and another commonly used one. It controls parameters better, helping out streaming and overall quality of browsing the internet. One of the most 'fair' algorithms out there, and is one of the most efficient algorithms to date.
yeah
A high speed TCP congestion control algorithm which uses a mixed loss/delay approach to calculate congestion windows. Its purpose is to target high efficiency, fairness, and minimizing link loss while keeping network elements load as low as possible.
reno
Basically the same as Tahoe, but if 3 of the same packets are received, it will halve the window, instead of reducing it to one. It changes the slow start threshold equal to that of the congestion window.
cubic
One of the best, most recommended TCP options available. Less aggressive, Inflects the windows prior to the event. Used in Linux.
Sweep to Wake, Sweep to Sleep, Double-tap to Wake (for these features, please build from branch master-s2w)
How do you get it?
That's a hard question to answer, surprisingly. You're free to flash the zip file below, but it's only the zImage. While this zip will include nearly everything you'll want or need, what you need for OC/UC is part actually of the dts. The dts is another piece that gets packed together with the zImage to make the boot.img. Unfortunately there's all sorts of ramdisk & permissions issues which can be caused by flashing a boot.img, so it's not recommended.
Please make a nandroid before doing anything! Backing up the boot partition takes all of a second and 16 megs of storage. Just do it! Also, do not hold us responsible for anything that happens to your device. It's worked fantastically for us, but you're flashing at your own risk.
Downloads for MM
Download for LP (no Sweep to Wake)
Download for LP (with Sweep to Wake)
The very best method of getting the kernel, is to have it compiled with the ROM itself (as with all kernels).
O.P. is a WIP. Will be adding and editing a lot, especially at first.
Special thanks to @izzaeroth for assisting with the Anykernel zip.
XDA:DevDB Information
Team-M8 AOSP kernel, Kernel for the HTC One (M8)
Contributors
fizbanrapper, smac0628, amirfida
Source Code: https://github.com/Team-M8/android_kernel_htc_msm8974/tree/master
Kernel Special Features:
Version Information
Status: Beta
Created 2015-11-10
Last Updated 2016-08-16
Want to get the most out of your kernel?
What does that mean to you? Battery savings? Performance? Balance between them?
The "most" is a difficult question to even attempt to answer. Even assuming we could define "balance between them", I still could not give you a set of settings that would work well for everyone. Not only are you all using different variants, but you're using different builds of different ROMs with different gapps packages, different apps, different usage habits, and in different areas of the country.
You really have to get an understanding of what different things do, then decide for yourself how you should customize your settings. Trial and error!
How did I get those scores on antutu? Here's a response I provided to that very question later in the thread:
fizbanrapper said:
I don't recall the exact settings, but I'll give you general guidelines.
When I test any kernel, I think it's critical to level the playing field as much as possible. I run it on my primary ROM with PAC ROM. I run few apps on it and disable anything that might sync in the background.
Disable all hotplugs and thermal drivers. Make sure your phone has been booted for a good 5 minutes so that your thermal temps have had a chance to come back down. Since you've disabled your thermal drivers, there's a decent chance you'll get a force reboot half way through the test if you're starting off with a high cpu temp already.
Used one of the zzmoove governor profiles. I think I used zram and disabled fsync too.
If my memory serves me right, this got me to back to back scores of 52776 and 52713.
Click to expand...
Click to collapse
Want great battery life?
Set your governor's max frequency to 268000 (yankactive is pretty good for this).
Set max frequency policy to 268000. Do the same for screen off max as well as any applicable input boost settings.
Set multicore powersaving mode to aggressive.
Choose one hotplug and choose the most conservative settings available.
Don't worry, your device won't completely listen to your request to only run at 268000 under all circumstances. Unfortunately every kernel I've ever run for this device (Team-M8, CM, Candy, DU, Slim, Blissful, Furnace, PAC, and B14ckb1rd) all disrespect my wishes! Abyssplug governor is the only notable exception here.
I'll try to provide more detailed settings when I get more time.
First
Not first! ?....oh wait...
SECOND!?
Great work getting this all together with so many sweet options!
Congrats on releasing this new kernel. I've updated the governor/scheduler guide to include missing description on Yankdemand for people who were curious
gsstudios
gsstudios said:
Congrats on releasing this new kernel. I've updated the governor/scheduler guide to include missing description on Yankdemand for people who were curious
gsstudios
Click to expand...
Click to collapse
Thanks! That was fast! I've updated the OP with your description.
I flashed this on the latest AICP (Android Ice Cold Project) and it kills my data. I'm also on Verizon if that matters...
GohanBurner said:
I flashed this on the latest AICP (Android Ice Cold Project) and it kills my data. I'm also on Verizon if that matters...
Click to expand...
Click to collapse
I've never heard of that happening g from a kernel. Could it be something else causing this? Anyone else experiencing this?
It has to be, I flash the kernel from CandyRom over it and data works again. Flash this again data doesn't work...
GohanBurner said:
It has to be, I flash the kernel from CandyRom over it and data works again. Flash this again data doesn't work...
Click to expand...
Click to collapse
It should work ok if compiled with the ROM. It's one of the downsides of the flashable zip.
Can a boot.img version of this be created? Or would that be just as good as a zip?
GohanBurner said:
Can a boot.img version of this be created? Or would that be just as good as a zip?
Click to expand...
Click to collapse
Well the boot.img would contain even more aicp-specific stuff. So if it was compiled from aicp's source, it would be fine as a boot.img.
If I compiled a boot.img from a ROM I've synced, it would cause even more compatibility issues than the zip.
I don't mind switching ROMs to use this kernel, which one are you running? I assume this will work with CM, correct?
GohanBurner said:
I don't mind switching ROMs to use this kernel, which one are you running? I assume this will work with CM, correct?
Click to expand...
Click to collapse
At the moment I'm on bliss. That's what it was compiled from. That used candy kernel though too, mostly. Let me look for a good build for you to try.
Try this
https://www.androidfilehost.com/?fid=24052804347848888
Try it without the kernel zip first, to make sure it works without it. Then go back and flash to get the updates.
Scozzar said:
What Kernel manager would you guys recommend for this kernel? I use Trickster, but it doesn't have the ability to select all of the hotplug options. With Trickster, I can only seem to choose between mp-decision or intelliplug.
Click to expand...
Click to collapse
I've been using kernel adiutor
Scozzar said:
Ah much better. I'm running all the Alucard hotplug and governor. Battery life isn't great, but I did just flash it twenty minutes ago.
Sent from my m8 using Tapatalk
Click to expand...
Click to collapse
Try zzmoove or a different hotplug. Alucard might not be the right choice for you.
@smac0628 is a current and equal contributor to this project. She's the one who put the work into Unicornblood. I'll update the OP shortly so that this is more clear.
Feel free to keep whining to @Mazda and the mods though. Though I don't think any of them care, it is entertaining.
What is it?
DatKernel is a fully customizable Kernel, with lots of new options that our Grand was never supposed to have. Have you ever thought of the perfect balance between battery life and craze performance? Here we go.
I first started compiling in October this year, inspired by @codekidX kernel and decided to build my own Kernel. I struggled some time to learn how to and implement my first functionalities and my first toolchain was Linaro 4.9 from @Christopher83. Since then, I've built hundreds of times with dozens of toolchains and, since everything is pretty much stable and different from other kernels around SGGD development, I had to share with you guys to further improve this kernel.
For me, the biggest problem were related to constant reboots caused by overflow in RAM or by incorrect execution when I started many apps. Couldn't open my maps with bluetooth playing music on my car and *BUM*, rebooted. Also, the performance was a little laggy sometimes, due to lack of upstreamed source. So let's waste no more time:
List of features
Toolchain and Compiling
Compiled with ArchiDroid's 5.2 toolchain, thanks to @JustArchi for his amazing job. GCC5.2 is very very stable.
Most of the kernel compiled with -O3 flags, but a lot of parts are compiled using -Ofast (goodbye O2 and Os hehe).
Using all the graphite optimizations that were possible to our phone, along with cortex-a9 tweaks.
Kernel Features
Dynamic management of dirty page writebacks, thanks to @faux123
Asynchronous file sync, thanks to @faux123
Dynamic filesync, thanks to @faux123
zram is enabled. It was backported also from @faux123 mako Kernel, and I did some commits to adapt it to 3.0.101, to lz4 support and to Zsmalloc.
Optimized ARM RWSEM / CRC32 algorithms, thanks to @coderdoid
Implemented frandom, thanks to @Ryuninferno
Updated Kernel Freezer and implemented Input Touchboost, thanks to @franciscofranco
Backport LMK RB trees from Motorola, thanks to @faux123
Lots of commits from 3.4.x and 3.12.x which came from CM's repos and @DespairFactor and @myfluxi. Some of them were crucial and obviously 3.0.101 lacked support of it.
Drivers like thermal, staging (LMK, binder, logger, gpio) and others were updated to last on CM-13.0, with some backports.
Ultra KSM implemented and enabled (UKSM)
vmpressure updated to CAF.
Boeffla-sound, thanks to @Andip71
cgroup_timer_slack and also dynamic cgroup_timer_slack management.
Boottime (it's useful for viewing boot time, implemented just because...). Thanks to @k2wl !!
oom_kill.c from @faux123 mako Kernel. This was a little hard to backport, but now I see how big the changes are until 3.4.xx
Zsmalloc which proved to be very useful when replacing Xvmalloc (the latter seems to be depracated).
Check my GitHub for much more awesome stuff...
Governors and I/O Schedulers
Updated and tweaked BFQ, SIO and DEADLINE. Also comes with CFQ, Noop, ROW and Sioplus.
Governors updated to @dorimanx version: ondemand, alucard, darkness, impulse, intelliactive, performance and zzmoove.
Interactive governor was updated according to @myfluxi repo and blu_active is the same used on @eng.stk kernel.
Do you want to see any governor here? Please request and I'll try to implement it!
CPU Hotplug drivers
intelliplug (aka intelli_plug) is implementes and working fine with intelliactive, with default options enabled.
zzmoove also offer lots of hotplugging options which are VERY stable, not a single random reboot or freezing during my usage with it.
Do you want any other CPU HOTPLUG driver? There are lots of options, if you want any of them, request it.
Attention
I'm not experienced as a Android Dev, as you can see most of features here were backported or upstreamed.
You can request features, but don't expect them to be implemented asap, because there are lots of tests to do. Please don't request DT2W and S2W, because they do not work properly on our phones (too much waste of battery for small benefits).
Also, if I have to backport or Upstream anything, be sure that is not as easy as it seems, cause 3.0.101 is pretty outdated nowadays, but we can't go much further than this.
Disclaimer
If your phone is bricked, exploded, vanished or something like this after installing this kernel, it's not my responsability. I'm sharing with you my personal builds and you're using at your own risk.
Be sure that I'll help you as I can, but this is supposed to be a kernel adapted to my usage and may not work for yours. Follow the instructions correctly and don't forget to hit thanks if you liked the initiative.
DO YOU WANT TO CUSTOMIZE YOUR EXPERIENCE? GO TO POST #2.
DO YOU WANT TO DOWNLOAD IT? GO TO POST #3.
Please, be kind on the comment section. I'll try to help you as much as I can
XDA:DevDB Information
DatKernel, Kernel for the Samsung Galaxy Grand Duos i9082
Contributors
neves4
Source Code: http://github.com/Neves4/DatKernel/
Kernel Special Features: This kernel is built with -O3 and -Ofast flags, with an optimized toolchain from GCC5.2. Lots of upstream code, new govs, zram, hotplug and a whole new experience in smoothness.
Version Information
Status: Beta
Current Beta Version: r20
Beta Release Date: 2015-11-27
Created 2015-11-27
Last Updated 2015-12-02
CUSTOMIZE YOUR EXPERIENCE
This part is still under construction, so bare with me!
How to customize the governors?
Most of the governors on XDA are based on some of the basic ones. As, I'm not the creator of any of these governors, I will only show you my personal recommendations and some links for you to read more. Let's go!
Interactive-based Governors
This are the new ones, which derived from very updated code, which is said to replace ondemand on the future. I really like these governors, as they're blazing fast and battery-life is almost the same as default ondemand. They're impulse, intelliactive, blu_active and interactive:
interactive: Upstreamed to lates on Code Aurora Forums (CAF), it is a very fast governor. Scales depending on load and goes really fast from minimum to max frequency. The battery is "OK" with this one, and you can tweak it to become exactly as you like, just by following this thread instructions: [GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life!, by @soniCron.
RECOMMENDATION: I've tweaked it for best performance already, so give it a try on default.
intelliactive: More performance focused than interactive, but achieves a great balance between battery-life and performance. You can tweak it using the same thread by soniCron that I told you in interactive.
RECOMMENDATION: The frequencies are on par with my i9082 common usage, and it fells a little better than interactive, but they're almost the same on benchmarks.
impulse: This one is focused on battery-life and works just fine, with some lag here and there (not that it really lags, lil stutters). You can tweak it using the same thread by soniCron that I told you in interactive.
RECOMMENDATION: Again, this one is tweaked for our i9082 and can save some battery if you use it on default.
blu_active: @eng.stk made this one, it's probably the fastes on interactive-based, but it's not very stable on my phone. You can try for yourself and see if is there any random reboots.
RECOMMENDATION: For now, you can try it, it's very snappy and smooth but not that stable. See if default works for you.
Ondemand-based Governors
Apart from being a little outdated, they still work great and bring really impressive results under the table. The governors ramp up and ramp down in defined steps, according to demand, but if you're multi-tasking, it stays on very high frequencies. The governors are: alucard, darkness, nightmare and ondemand.
ondemand: Not much to say. It's the default governor because it's very stable and you can find much information about it on this link: CPU Governors, Hotplugging drivers and GPU governors
RECOMMENDATION: Use it by default, rock-solid stable.
Darkness: It works fast and is a new gov. Liked it, it's good by default.
RECOMMENDATION: Use it by default, may be stable.
Nightmare: This one originated Darkness, and is probably the same with bigger code.
RECOMMENDATION: Same recommendations as Darkness, use it by default.
Alucard: Pretty impressive governor, made by @alucard_24 and maintained by @dorimanx.
RECOMMENDATION: Default is OK, it's the best under ondemand-based governors.
Conservative-based Governors: zzmoove
Maintain the phone on lowest possible frequency whenever possible. The only governor 'round here is zzmoove and DUDE: it's great. Thanks to it, I have a Crazy-smooth experience and awesome battery-life, so I really liked the way it works.
zzmoove: Created by @ZaneZam and maintained by him and @Yank555, this governor focus is to maintain frequency as low as possible. In order to do that, it limit frequencies whilst the screen is off or hearing music, in example, so it's very adaptive to your usage if you tune it right. It has 9 profiles, which are described below, on "Click to show content"
* ------------------------------------------------------------------------------------------------------------------------------------------
* - (1)'def' -> Default -> will set governor defaults -
* ------------------------------------------------------------------------------------------------------------------------------------------
* - (2)'ybat -> Yank Battery -> a very good battery/performance balanced setting -
* - DEV-NOTE: highly recommended! -
* ------------------------------------------------------------------------------------------------------------------------------------------
* - (3)'ybatext'-> Yank Battery Extreme -> like yank battery but focus on battery saving -
* ------------------------------------------------------------------------------------------------------------------------------------------
* - (4)'zzbat' -> ZaneZam Battery -> a more 'harsh' setting strictly focused on battery saving -
* - DEV-NOTE: might give some lags! -
* ------------------------------------------------------------------------------------------------------------------------------------------
* - (5)'zzbatp' -> ZaneZam Battery Plus -> NEW! reworked 'faster' battery setting -
* - DEV-NOTE: recommended too! -
* ------------------------------------------------------------------------------------------------------------------------------------------
* - (6)'zzopt' -> ZaneZam Optimized -> balanced setting with no focus in any direction -
* - DEV-NOTE: relict from back in the days, even though some people still like it! -
* ------------------------------------------------------------------------------------------------------------------------------------------
* - (7)'zzmod' -> ZaneZam Moderate -> NEW! setting based on 'zzopt' which has mainly (but not strictly only!) 2 cores online -
* ------------------------------------------------------------------------------------------------------------------------------------------
* - (8)'zzperf' -> ZaneZam Performance -> all you can get from zzmoove in terms of performance but still has the fast -
* - down scaling/hotplugging behaving -
* ------------------------------------------------------------------------------------------------------------------------------------------
* - (9)'zzinz' -> ZaneZam InZane -> NEW! based on performance with new insane scaling active. a new experience! -
* ------------------------------------------------------------------------------------------------------------------------------------------
* - (10)'zzgame' -> ZaneZam Gaming -> NEW! based on performance with scaling block enabled to avoid cpu overheating during gameplay -
* ------------------------------------------------------------------------------------------------------------------------------------------
* - (11)'zzrelax'-> ZaneZam Relax -> NEW! based on moderate (except hotplug settings) with relaxed sleep settings -
* ------------------------------------------------------------------------------------------------------------------------------------------
RECOMMENDATION: I selected for default "zzinZ", profile 9, because it really is what I want: lagless when using, low frequencies when not using. And I got it, so I suggest you to have a look.
What about I/O Sched?
Well, I've never worried much about I/O sched. When pawitp put BFQ as default on CM12.1, I thought that it was really good, but really unstable as well. The two I like the most are: SIO and Deadline for general usage (multitasking). If you like to play heavy games, use ROW. You can try the others and actually read this article that talks everything about I/O Schedulers: I/O Schedulers - Android Modders Guide
Damn, need that Hotplug asap!
i9082 phones, have lots of power and sometime doesn't need all cores online. That's where come hot-plugging, some cores can be turned off with no overhead or noticeable lag.
The options are: intelli_plug and zzmoove hotplugging feature.
intelli_plug: The first option is a widely spread hotplug driver, made by @faux123 and it works great for what it's doing. I recommend tweaking it for you needs and the best governor to integrate with it is intelliactive, made by faux123 as well. It'll actually waste battery instead of saving if you are a power user that loves lots of multitasking, because it'll be constantly turning CPU1 on and off. Note that while using this, make sure your tasks with Screen Off are not that big, because your phone must handle that with just 1 core, which can lead to a kernel freeze (than you have to reboot). It's recommended if you usage is very light and you want a 2 days long battery.
zzmoove hot-plugging: The second one is a more concise approach, because you'll need only the governor to handle hot-plugging. Here you can activate the hotplug on governor's tunables (change to disable_hotplug = 0 and disable_hotplug_sleep = 0) and it works by shutting down CPU1 whenever the load is not that big. Again, if you're a power user, beware that this can actually shrink you battery time, so use hotplug if you doesn't need much complex things to be done when screen is off.
frandom - Don't forget to use this script in your init.d folder
Create a new file named "00frandom" and in order to frandom work, you need to use this code:
Code:
#!/system/bin/sh
# Script to launch frandom at boot by Ryuinferno @ XDA
insmod /system/lib/modules/frandom.ko
chmod 644 /dev/frandom
chmod 644 /dev/erandom
mv /dev/random /dev/random.ori
mv /dev/urandom /dev/urandom.ori
ln /dev/frandom /dev/random
chmod 644 /dev/random
ln /dev/erandom /dev/urandom
chmod 644 /dev/urandom
My Recommendation
zzmoove really got me, because it works like interactive but it tries to always lower the frequency, which is great. Apart from that, intelliactive is very fast, almost the same as interactive. So, for craziness zzmoove and for performance, intelliactive (UNDER CONSTRUCTION, JUST A QUICK PREVIEW).
### Anything else there is to customize is in Kernel Adiutor, which is a great app thanks to @Grarak
Download here!
DOWNLOADS
First things first: how to install?
Backup your EFS partition and do a full nandroid of your system. Never did the latter, but my backup of EFS partition saved me multiple times when I was a noob in flashing.
Download last version which will be attached on my GitHub Release page (download the zip). Will try to attach it to the thread here as well.
You're installing for the first time? Factory reset your phone and install the lastest version of CM12.1 from @pawitp. Be sure to do this before anything weird happens. You're advised! (the reason is that when you flash different kernels, sometimes they're on different kernel version on crucial parts, which leads system to incompatibility)
Already installed once? Just dirty flash it then and profit.
Reboot your phone.
Lemme download this, bro!
FOLLOW THE SETTING UP HERE /\. It's the same for all kernels you've used, but please, EFS partition backup is a must.
The last version will be on my GitHub's release page, on this link:
To download it, click on "DatKernel-rXX.zip" under Download tab on Latest release. Trouble downloading it? PM me so I can send it to you!
>>>> CLICK HERE TO DOWNLOAD <<<<
Thanks, nice to see a new kernel.
Will try it when ready
@RichyE with you want to try it now, I just uploaded r20 to GitHub, give it a shot!
https://github.com/Neves4/DatKernel/releases/tag/r20
Download "DatKernel-r20.zip" file.
And for now, I'm having crazy smooth results with zzmoove, try it
Oh, and remember to have CM-12.1 ready to reflash, just in case something goes wrong.
SWAP
is this swap enabled(for swapping the sdcard memory to increase the ram)??
ayush.gl said:
is this swap enabled(for swapping the sdcard memory to increase the ram)??
Click to expand...
Click to collapse
It is enabled on configs, but when I type "free" in terminal it shows no swap device being used, which is weird. Can you try it and see what happens when you type free in terminal?
Flashed it on RR first boot gave problem, had to pull batery but after that it worked.
Even a couple of reboots went smooth
@RichyE is it working OK now? I'm sorry to hear you had trouble...
Have you tried the new govs?
Thanks
@neves4 It's working now without a problem
At the moment trying zzmoove and Sioplus
Zzmoove (or kernel??) giving a little trouble I think.
Sometimes the phone doesn't switch on and I have to pull battery.
Switching back to my originel kernel for the moment and will try another time.
everything was smooth but YouTube app hangs a lot!
I just flash it normally and using zzmove and sioplus and no problem it works very smooth :good:
RichyE said:
Zzmoove (or kernel??) giving a little trouble I think.
Sometimes the phone doesn't switch on and I have to pull battery.
Switching back to my originel kernel for the moment and will try another time.
Click to expand...
Click to collapse
Hey Richy, we can maybe solve this problems. I've sent you a PM, take a look
aditya_pan said:
everything was smooth but YouTube app hangs a lot!
Click to expand...
Click to collapse
Bro, what are your configs? Are your using BFQ or hot-plugging?
abhishekcma said:
I just flash it normally and using zzmove and sioplus and no problem it works very smooth :good:
Click to expand...
Click to collapse
Thanks for trying it
I am going to try your kernel soon but is it stable enough to be used as a daily driver????
And one request if you don't mind can you develop ROM for our device with marshmallow support???
@neves4 is it kit kat compatible?
neves4 said:
Hey Richy, we can maybe solve this problems. I've sent you a PM, take a look
Bro, what are your configs? Are your using BFQ or hot-plugging?
Thanks for trying it
Click to expand...
Click to collapse
I was using zmoove governor and sioplus as the io scheduler. I didn't know what hot-plugging was, so didn't mess with it. appreciate your effort man.
Do you plan to make it compatible for aosp 6?
Sent from my GT-I9082 using Tapatalk
hi
thanks for the kernel..will trry it soon.
i have one doubt.
zzmove needs hotplugging and as far as i know our kona platform restriced it in kernel code.
thats why RichyE have problems with zzmove.
anyways may be you have solved that..good luck...
sai milind said:
I am going to try your kernel soon but is it stable enough to be used as a daily driver????
And one request if you don't mind can you develop ROM for our device with marshmallow support???
Click to expand...
Click to collapse
Hey man, it's completely stable for me. Smooth, fast and with great battery, I'm using r20 with no random reboots for 120 hours, and I'm a power use (always using bluetooth, with 3G on and GPS on High Accuracy). If you want to be sure that it's going to work, do a clean install and install lastest CM12.1 that it'll be stable as a rock
And about the ROM with marshmallow support, I'm waiting until pawitp gets AOSP-6.0 stable, because there are some complications to make it work on our phones
daneal2u said:
@neves4 is it kit kat compatible?
Click to expand...
Click to collapse
Good question! I've never used KitKat, because I used to own an iPhone. Since this kernel is based on Frost Kernel source code, I'm almost sure it works on KitKat, and the others to 4.1.2. Can you try it and report back? Be sure to have a copy of the ROM you're using, because anything goes wrong, you just have to flash the ROM back.
aditya_pan said:
I was using zmoove governor and sioplus as the io scheduler. I didn't know what hot-plugging was, so didn't mess with it. appreciate your effort man.
Click to expand...
Click to collapse
Thanks for the answer
It's known that zzmoove has problems with big loads, so I think that when you were using YouTube, you were probably using other apps on background, which made system a little unstable. Can you try interactive or intelliactive and see if the same happens?
rishabh56 said:
Do you plan to make it compatible for aosp 6?
Sent from my GT-I9082 using Tapatalk
Click to expand...
Click to collapse
I would love to, but AOSP 6.0 is still not stable for our phones, as pawitp is still fixing some stuff. But as soon as everything is OK there, I'll be doing AOSP-6.0 compatibility patches if needed
The Schwifty Kernel (Yeahhh, Get Schwifty)
Hello guys welcome to the Schwifty Kernel! If you watch the show "Rick and Morty" you will understand why I named it this if you don't understand well either youtube it or just don't worry and enjoy the sh*t out the kernel anyways hehe. Alright lets get Schwifty, here's all the info about the kernel in a way that will help you decide how you want to set up your phone! The second post will contain changelogs and third post, well not sure yet. But enjoy!!
Basic Specifications/Information:
Based On Axon 7 LoS 16.1 Kernel Source
Updated to the latest linux kernel source (3.18.126)
Built with Custom CrossTool-NG Toolchain (GCC: 8.2.0)
Allow 5-10 to settle in after booting up for better usage
Take the time to read all the information to get an understanding on the kernel (Will help with less bug reports)
If you report a bug please search before posting and give all information about your issue (Such as rom, kernel version, kernel setup... ect)
I will edit the page with dates when there is something new added such as govenors, schedulers ect...
I/O Scheduler Information - I/O:
NOOP - Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
DEADLINE - The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number. Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.
BFQ - Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
ZEN & ZEN v2 - Based on the Noop, Deadline and SIO I/O schedulers. It's an FCFS (First come, first serve) based algorithm, but it's not strictly FIFO. ZEN does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones.
MAPLE(8/30) - is based on the Zen and Simple I/O schedulers. It uses ZEN's first-come-first-serve style algorithm with separate read/write requests and improved former/latter request handling from SIO. Maple is biased towards handling asynchronous requests before synchronous, and read requests before write. While this can have negative aspects on write intensive tasks like file copying, it slightly improves UI responsiveness. When the device is asleep, maple increases the expiry time of requests so that it can handle them more slowly, causing less overhead.
Governor Information - CPU:
Interactive - Interactive scales the clockspeed over the course of a timer set by the kernel developer (or user). In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. It is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency. Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above. Interactive is the default governor of choice for today's smartphone and tablet manufacturers.
Ondemand - Ondemand is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold, the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google's Interactive governor.
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.
GPU Governors:
Adreno Idler - It is an idling algorithm, an efficient workaround for msm-adreno-tz's overheads. Main goal is to lower the power consumptions while maintaining high-performance. Since msm-adreno-tz tends to *not* use the lowest frequency even on idle, Adreno idler replaces msm-adreno-tz's algorithm when it comes to calculating idle frequency(mostly by ondemand's method). The higher frequencies are not touched with this algorithm, so high-demanding games will (most likely) not suffer from worsened performance.
Simple - An open-source alternative to Qualcomm's closed-sourced governors. Developed by Faux123, it is highly customisable which will allow more fine-grained control over how the GPU scales up and down.
simple_ondemand[/b] - As the name implies, it is a simpler version of the CPU governor ondemand. simple_ondemand will ramp up the frequency when a load is detected. It has a good balance between performance and battery savings.
msm-adreno-tz - The default GPU governor used by Qualcomm for their adreno GPUs. It is based on the ondemand governor but is biased towards performance, therefore it should give better performance in games but less battery life.
Performance - As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don't care about your battery life.
Powersave - Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.
Userspace - This governor basically allows the user is able to set a desired frequency for the GPU to run at.
cpubw_hwmon - A hardware monitor based governor that attempts to determine bandwidth (BW) needed by CPU and other hardware. Because it samples bandwidth using polling intervals, it has been made to be biased towards performance to compensate for the possible slower response times during heavy loads.
MSM Cpufreq - The MSM CPUfreq governor determines the CPU to DDR bandwidth vote based on the current CPU frequency of all the active CPUs. In other words, this governor scales based on CPU usage which could mean more 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.
Updated the performance is cpufreq
Lots of UPSTREAM changes to cpuidle and schedulers
Some under and overclocks with how the phone idles and returns
Added a State Notifyier
Added CAD Project
Imported Boeffla Wakelock Blocker v1.1.0
Updated Kcal Support
Fixed Various Issues
Low Persistence Fixed For DayDream
Selinux Switcher Between Permissive & Enforcing (Please install the Magisk SELinux Manager)
And a whole lot of other sh*t, view the github to see all the changes
Credit:
@OrdenKrieger
@Unjustified Dev
@Skrem339
Tester:
@kingracer
@KevinX8
@Masterjuggler
@Choose an username...
@docentore
@Infy_AsiX
Disclaimer: I do not and will not take any responsibility towards anything that happens to your phone after flashing.
If you would like to donate a beer or a blunt feel free, its not obligated though! Each donation is appreciate by being added to OP!
XDA:DevDB Information
[KERNEL][OREO][AOSP] Schwifty Kernel | Custom | 6/8/17 |, Kernel for the ZTE Axon 7
Contributors
SaintZ93
Source Code: https://github.com/SaintZ13/schwifty_oreo_axon7
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: v1
Stable Release Date: 2018-06-24
Created 2018-06-25
Last Updated 2018-06-24
Install Instructions:
Boot To Recovery
Flash Schwifty Kernel
Wipe Dalvik & Cache
Re-flash Magisk
Downloads:
Stable Release: vR5 Changelog (12/12/18)
Download:
https://www.androidfilehost.com/?fid=11410963190603873368
Click to expand...
Click to collapse
MD5: ef8222968aaea32fed85245d53599c56
Kernel Size: 13.6MB
Stable Release: vR4 (Treble & Non-Treble)
Changelog (8/30/18)
Download:
https://androidfilehost.com/?w=files&flid=281523
Click to expand...
Click to collapse
MD5: Treble - 55fb1a7e7dade9f560725f5bc135e4d7
Non-Treble - 69d034f21ba8b39330633c1b96bf8c97
Kernel Size: 13MB
Stable Release: vR3 (Treble & Non-Treble)
Changelog (7/30/18)
Download:
Treble said:
https://www.androidfilehost.com/?fid=5862345805528062503
Click to expand...
Click to collapse
Non-Treble said:
https://www.androidfilehost.com/?fid=5862345805528062511
Click to expand...
Click to collapse
MD5: Treble - f30ef3e8220146331f657195d46bc8b8
Non-Treble - dc055bcc684df594820e741c3e912be2
Kernel Size: 10.6MB
Stable Release: vR2
Changelog (7/3/18)
Download:
https://www.androidfilehost.com/?fid=11050483647474833482
Click to expand...
Click to collapse
MD5: 5f275eb139681e005f28986c6649560b
Kernel Size: 10.9MB
Schwifty Kernel: Initial Release (6/24/18):
Download:
https://www.androidfilehost.com/?fid=674106145207498193
Click to expand...
Click to collapse
MD5: c30d7ed7c4e7b2843f3ae83e9e75509b
ROM Size: 10.9MB
Reserved
Trying this right now, so far it seems to be stable. Battery life seems to be less right now but that may be due to other factors I'm still investigating.
Nice,new kernel.But why should i use this,and not Hellsgate?
Predatorhaze said:
Nice,new kernel.But why should i use this,and not Hellsgate?
Click to expand...
Click to collapse
Although fast, hellsgate kernel hasn't been kind to my device's stability personally speaking.
This could be more stable, since it doesn't seem to add hoards of features (and potential complications with them).
Predatorhaze said:
Nice,new kernel.But why should i use this,and not Hellsgate?
Click to expand...
Click to collapse
Try searching Schwifty kernel on Google, this kernel isn't new If I remember correctly there were great reviews for this kernel on the other device(LG V20). I don't mean that Hellsgate is not as good, I'm just saying this kernel has its own unique advantages(while Hellsgate is a mighty kernel with loads of features and great performance, so it's also no worse)
About DAC
DAC is working in this kernel?
Very nice kernel, it's stable, the battery holds very nicely and it's powerfull, the UI doesn't lag.
Thanks for your work!
is F2FS supported?
leska said:
is F2FS supported?
Click to expand...
Click to collapse
I tried, it seems so. F2FS and encryption working on my device (exfat also).
Good battery life. Fast and smooth. Stable.
Thank u!
Running this kernel for for about 12 hours now. Seems solid and I find my device to be snappier vs HellsGate. Battery life appears to be solid as well.
del
can someone report about battery life? and does this include COFB(Conservative Optimized For Battery), and it optimized for battery ? (Everything from CAD kernel)
Could you please build this for stock B12? Everything except wifi and hotspot works.
hmm on my device the kernel is a real battery killer.. can barely reach 2.5h screen on time where hellsgate gives me double
switching back now...
Guido83 said:
hmm on my device the kernel is a real battery killer.. can barely reach 2.5h screen on time where hellsgate gives me double
switching back now...
Click to expand...
Click to collapse
What kernel/ROM did you flash this over?
EBeatFLA said:
What kernel/ROM did you flash this over?
Click to expand...
Click to collapse
AEX latest build
New build will be coming within the next couple of days guys, stay tuned! Check the github for new changes.
Hello all.
After about a month of researching and testing with the Galaxy S5, I'm finally happy with my SmartKernel profile, with the interactive governor carefully tuned, using known resources and countless trials and errors, as well as other various tweaks, like VM and I/O scheduler, and decided to publish on it's own thread.
The main resources I've used for the Interactive governor tuning includes the well known:
Android Modders Guide;
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life! for Nexus 5X; and it's twin
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life! for HTC Evo 4G.
First of all, this tweaks should be a little sensible to the ROM, kernel, apps, and other tweaks your using. Like, I just found out that Havoc pie style quicktile settings use way more juice then if I turn it off and go back to Oreo default. Bellow you will see the apps I mainly crafted this profile in mind.
For reference: I have a klte with latest Oreo Havoc installed, nano OpenGapps, Magisk and the SmartPack kernel. For apps I use Facebook lite, cause the normal app is just a big hog, whatsapp and instagram social apps. Chrome. I don't use the Google App or Greenify(uninstall/delete velvet). And play lots of games like Clash Royale, Star Wars Force Arena and Arena of Valor. BetterBatteryStats.
And a lot of random apps that normally don't stay on the background.
DESCRIPTION
On the SmartPack manager profile:
. HIghly Efficient Interactive Governor Tunables (most important part);
. No Touchboost or any other boost, only the governor dictates to CPU in which clock it should to be;
. Overclock disabled, but can be enabled at you will;
. No underclock, I do undervolt my CPU but this you need to find your specific device numbers, mine won't cut;
. LazyPlug Hotplug with all 4 cores on all the time (better performance while using and battery savings while at idle);
. I/O Schedulers: ZEN (the L-Speed profile complement this part, with it's scheduler tunables);
. READ-AHEAD internal 1024kb (for 16GB or more) and external 512 kb (for my 8GB SDCard, adjust accordingly to yours SD Card size conform described here
. Adreno Idler disabled: it doesn't make any effect;
. Speaker Driver Leakage disabled and Boeffla Sound enabled with 0 gain as it does make a difference, at least with ViperFX magisk module installed;
. Screen minimum RGB set to 1 (0 won't stick), for a darker dark on our AMOLED, plus some tweaks;
. Led blinking fade enable;
. VM tweaks: dirty_ratio 30 and dirty_background_ratio 15; for minor battery improvement, with a perceptible lower termperature/cpu usage and almost imperceptible performance hit;
. VM tweaks: page-cluster 1; for better multitasking/memory management
. VM tweaks: oom_dump_tasks 0; disable depuration of dumping tasks, less cpu needed.
. LMK values: 32 48 64 128 176 208 (MBs)
L-Speed Profile
. Logging and I/O stats disabled;
. Animations speed set to 0.25x;
. System battery save trigger at 20%;
If you need to provide or read logs, enable logging and i/o stats back on l speed; i/o stats and oom_dump_tasks 1 on smartpack manager
INSTALLATION
Unzip the attached file and import with SmartPack Manager:
The attached profile should be imported, applied and marked as to run "On Boot" to make effect. It will only work with SmartPack Manager and Kernels for both Nougat and Oreo, maybe even Pie. Just try it, and report back. If you wanna fine tune it. You need to use an app or enable the "show cpu clocks" option if your rom supports it (like Havoc, RR and many more), and monitor at which frequencies the lags happens, while doing the jobs you want the CPU to be efficient at. And mainly tweak the target_load according, maybe above_high_speed delays of 1,7GHz clock and above. You need to read the guides more in-dept too see exactly how to do it, but I'll paste here the most important parts on how to tweak this settings more to your Galaxy S5, with your particularly apps and ROM:
soniCron said:
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (384Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 710Mhz/864Mhz rates, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "710000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
If you need to exceed your nominal clock rate for a particular task, first measure it again just to be sure you had it correct. If you did indeed have it correct, leave it at your nominal clock rate and adjust the value after the colon next to the task frequency you're tuning downward in increments of 5. For example, if my setting of "864000:80" is still not sufficient, I will adjust it first to "864000:75", then "864000:70", and so on until the task is smooth. However, it almost certainly won't come to this, but if you reach ":50" and the task still isn't performing how you want, set it back to ":80" and increase the clock step once more, then decrease the ":80" until it is smooth.
Do the same for each other frequency in your master clock rate list until you are satisfied. If you have chosen to use more than 2 primary clock rates, add them and use ":##" values between the two surrounding frequency values.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
Adjust High Load Clock Rates
You're almost done! Now you can leave everything as is and be satisfied with your amazing, buttery smooth, snappy experience, or you can optionally tweak things further to either increase the responsiveness of high load tasks (such as loading image previews in Gallery) or increase battery life somewhat.
Adjust the final delay value in above_highspeed_delay to suit your needs. The default ("150000") means that the CPU load at the highest set frequency (default "1026000") will have to be sustained for 150ms before it allows the load to go above that frequency. Increasing this value will prevent the CPU from reaching higher frequencies (which may be unnecessary) as often, saving battery life. This will come at the expense of burst-type high CPU load tasks. Reducing it will allow the CPU to reach higher frequencies more often, at the expense of battery life. However, adjusting this is probably unnecessary, as it will most likely not yield any perceptible difference in performance. It is recommended to leave this value at its default.
Click to expand...
Click to collapse
Besides CPU Voltage and Battery, all tabs on the manager are modified and tuned to achieve best performance, while having best efficiency possible. Is not a battery or a performance, but a efficiency profile.
Refer to this thread if you wanna undervolt your device with a well know secure margin for the CPU Snapdragon 801 2.5ghz MSM8974AC, which our Galaxy S5 contains:
[GUIDE] Snapdragon 805/801/800/600 Clock & Voltage (PVS bin) guide by HD2Owner I've managed to achieve much lower voltages then PSV15+ devices (refer to the sheets).
I also attached the excel spreadsheet I've made with all this thread information, both governor guide equations on target loads, undervolting guide findings, and made my own base calculations and settings. Feel free to use, modify, and discuss it with me. You will see that I based the most efficient clocks in an original thought about which ones are the most efficient, instead of plotting the differentials between voltages of each clocks, I did plotted the difference of the clock divided by voltage, which on itself should be how much voltage 1 mhz uses, on each clock rate. So, the higher the number, more speed each clock rate give us by voltage used. It's kinda complicated and idk if I explained it the right way, and even if it really makes sense under scrutiny, but I couldn't think why not myself, so, any inputs are welcome.
I own my thanks to all the following XDA fellows, without them, I could not have achieved this:
@sunilpaulmathew for the SmartPack Kernel which is the only kernel for the S5 that can turn that damned MPDecision off and SmartPack Manager;
@soniCron for both of the governos Guides;
@Saber for the Android Modders Guide which is immensely helpful.
CHANGELOGS
L-Speed Profile (download the app on PlayStore):
011118 lspeed profile
- first release
031118 lspeed profile
- Removed most tweaks, only left minor stuff, refer to the OP.
L Speed profile is not really needed, SmartPack will do 99% of the job.
SmartPack Manger Profile (download the kernel and the app here):
301018
- first release.
011118 smartpack profile:
- A few Interactive governor tweaks;
- Removed Virtual Memory and LMK tweaks, let it on default or use L-Speed to optimize, as it does a much better job then me.
031118 smartpack profile:
- Governor tunning: better high load management;
- Included back only 3 sane VM configurations, no more freezing, better cooling (less cpu needed, while performance barely took a hit)
- Sane LMK configurations, kills apps not being used faster, retain some multitasking while not let it slow down the device
081118 smartpack profile:
- target_load (no changes up to 1497600) ...1728000:89 1958400:91 2265600:95 -> ...1728000:88 1958400:90 2265600:95
- above_hispeed 20000 1190400:60000 1497600:64000 1728000:77000 1958400:84000 2265600:130000 -> 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000
- external storage read-ahead from 512 -> 2048 (because I've gone from a 8GB to a 32 GB SDCard, ADJUST YOURS ACCORDINGLY TO https://androidmodguide.blogspot.com/p/io-schedulers.html)
- cleaned unused and already default values from profile
101118 smartpack profile:
- Turned Alucard off, accidentally activated it with Lazyplug also enabled, not good!
- Managed to go 1 point higher on freq 1497 MHz, the 2 hotplugs enabled were messing with me trying to test this change before, also 1 point lower on the idle freq 268 MHz for smoother scrolling while still staying at freq 268 while idle. And some more high load optimizations now that I only got 1 hotplug enabled as it should always be.
- target_loads from 268800:29 ... 1497600:86 1574400:5 1728000:88 1958400:90 2265600:95 to -> 268800:28 ... 1497600:87 1574400:5 1728000:89 1958400:91 2265600:94
- above_hispeed 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000 -> 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000
- dirty_background_ratio 15 -> 10
221118 smartpack profile:
. Reverted new SmartPack Kernel v14r4 changes to Virtual Memory back to original default configurations, if you've have had reboots this should fix it, please report back here and/or the kernel's thread;
. More changes to Interactive governor aiming to optimize high load scenarios according to the profile philosophy:
. above_hispeed_delay 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000 -> 20000 1190400:60000 1728000:74000 1958400:80000 2265600:105000;
. Enabled fast charge configurations, set at 1200 mhA as I found it's a good charging speed without heating the phone too much on my hot city, nothing you can't change at your will.
241218 smartpack profile:
. Restored missing min_sample_time tunable since 081018 profile
. dirty_ratio 30 -> 25
. General cleanup
. Tested on Pie
@justjr
Nice work friend. Great to see that your finally open a place to share your findings. In my opinion, your profile should work on any klte device with minimum kernel support. I haven't seen much SmartPack specific stuff in your profile except some hotplug related things. So, if you make it as a shell script instead of KA/SP-Kernel Manager profile, it shall be beneficial for everyone. Anyway, as usual, I'll kang your changes to my kernel default profile
sunilpaulmathew said:
@justjr
Nice work friend. Great to see that your finally open a place to share your findings. In my opinion, your profile should work on any klte device with minimum kernel support. I haven't seen much SmartPack specific stuff in your profile except some hotplug related things. So, if you make it as a shell script instead of KA/SP-Kernel Manager profile, it shall be beneficial for everyone. Anyway, as usual, I'll kang your changes to my kernel default profile
Click to expand...
Click to collapse
I think this profile should work on original Kernel Adiutor, or any fork of it, shouldn't it?
It should work on any other kernel if the changes really stick, and uses the same paths, but MPDecision will mess with frequencies all the time. It would still follow the governor tunables anyway, but it will interfere with it and in the end will not gain too much efficiency out of it.
Actually I only state it is for SmartPack specifically because of the fact that is the only one I can disable MPDecision on our device, and because I included all the tweaks other then just governor tweaks.
Actually I'm kinda lazy right now, but I could do a shell script if any demand for it shows up.
justjr said:
I think this profile should work on original Kernel Adiutor, or any fork of it, shouldn't it?
It should work on any other kernel if the changes really stick, and uses the same paths, but MPDecision will mess with frequencies all the time. It would still follow the governor tunables anyway, but it will interfere with it and in the end will not gain too much efficiency out of it.
Actually I only state it is for SmartPack specifically because of the fact that is the only one I can disable MPDecision on our device, and because I included all the tweaks other then just governor tweaks.
Actually I'm kinda lazy right now, but I could do a shell script if any demand for it shows up.
Click to expand...
Click to collapse
Well, official KA (free version) doesn't allow to import profiles (paid feature), but all other mods does.
and yes, it is supposed to work on every klte device as long as the sysfs paths exist. Means it should work on any custom Kernel with lazyplug support (most of the other stuff are actually included in the stock kernel itself). Of course, the default settings provided by the kernel devs might conflict. e.g., as you said, MPDecision, although the line "stop mpdecison" in your profile will disable it. By the way, I'm not the only one who disabled mpdecision and relay on other hotplugs in this klte community
sunilpaulmathew said:
Well, official KA (free version) doesn't allow to import profiles (paid feature), but all other mods does.
and yes, it is supposed to work on every klte device as long as the sysfs paths exist. Means it should work on any custom Kernel with lazyplug support (most of the other stuff are actually included in the stock kernel itself). Of course, the default settings provided by the kernel devs might conflict. e.g., as you said, MPDecision, although the line "stop mpdecison" in your profile will disable it. By the way, I'm not the only one who disabled mpdecision and relay on other hotplugs in this klte community
Click to expand...
Click to collapse
Oh, really? Which one? I must had missed it. I've tested all kernels I could find. At least all the remotely up-to-date, like venom, tuned and boeffla kernels. I didn't see any option to change hotplugs on any. There were hotplug profiles, to keep cores online and stuff, but everyone of them keep changing min and max frequency at MPDecision will.
justjr said:
Oh, really? Which one? I must had missed it. I've tested all kernels I could find. At least all the remotely up-to-date, like venom, tuned and boeffla kernels. I didn't see any option to change hotplugs on any. There were hotplug profiles, to keep cores online and stuff, but everyone of them keep changing min and max frequency at MPDecision will.
Click to expand...
Click to collapse
Boeffla and Venom largely depends on MPDecision. However, as I remember correctly (on the basis of the code review, not from my experience, I never used it by myself), the Tuned kernel by @fbs disabled MPDecision upon booting to work well with its own Tuned hotplug.
sunilpaulmathew said:
Boeffla and Venom largely depends on MPDecision. However, as I remember correctly (on the basis of the code review, not from my experience, I never used it by myself), the Tuned kernel by @fbs disabled MPDecision upon booting to work well with its own Tuned hotplug.
Click to expand...
Click to collapse
I tested it too. And although he claims he uses hes own hotplug, it behave the same as boeffla and venom, it has the same profiles, and it does changes min and max freq out of my control.
justjr said:
I tested it too. And although he claims he uses hes own hotplug, it behave the same as boeffla and venom, it has the same profiles, and it does changes min and max freq out of my control.
Click to expand...
Click to collapse
no it doesn't change any freqs
it works by disabling or enabling cores, just that.
if any cpu reaches the maximum frequency, it enables one more core (as the other ones are already giving their best)
if any cpu reaches the minimum frequency too many times, it disables it (as it doesn't seem to be needed)
so in any moment you can have all 4 cores enabled or only 1. even with display on or off, it doesn't matter
mpdecision will NEVER let you use just 1 core, and it doesn't react as fast: battery hog
fbs said:
no it doesn't change any freqs
it works by disabling or enabling cores, just that.
if any cpu reaches the maximum frequency, it enables one more core (as the other ones are already giving their best)
if any cpu reaches the minimum frequency too many times, it disables it (as it doesn't seem to be needed)
so in any moment you can have all 4 cores enabled or only 1. even with display on or off, it doesn't matter
mpdecision will NEVER let you use just 1 core, and it doesn't react as fast: battery hog
Click to expand...
Click to collapse
Alright, sorry then, it seems my memories got clouded or something, as I've tested it about a month ago. I might go back any day just to test that. Thanks for giving us one more kernel option! :good:
UPDATE OP WITH
Description
Changelogs
New profile 011118, changelog:
. Few governor tweaks
. Removed Virtual Memory and LMK tweaks, let it on default or use L-Speed to optimize, it does a much better job then me
Also uploading the L-Speed profile I use so those who want to use it like I do, but you can choose any VM and LMK profile that fits your needs on the app. Just don't use the governor tuner because it will mess with my tunings, and l-speed governor tuning is a generic one for all devices, VM and LMK is OK to use generic tweaks, but not on governor.
@sunilpaulmathew I took a look at l-speed virtual memory and lmk profiles and they make incredible sense, take a look yourself, they may be what you need to put o that spectrum profiles, because above all they are device independent and do make a noticeable difference.
Is it valide for stock rom (6.0)?
lollazzo said:
Is it valide for stock rom (6.0)?
Click to expand...
Click to collapse
What kernel? It should work if the kernel have lazyplug or alucard hotplug, if is the late you just have to enable it.
Updates
SmartPack Manager Profile 031118:
. Governor tunning: better high load management;
. Included back only 3 sane VM configurations, no more freezing, better cooling (less cpu needed, while performance barely took a hit)
. Sane LMK configurations, kills apps not being used faster, retain some multitasking while not let it slow down the device
LSpeed Profile 031118:
. Removed most tweaks, only left minor stuff, refer to the OP.
L Speed profile is not really needed, SmartPack will do 99% of the job.
OP: descriptions for both profiles updated.
New profile.
I returned to Nougat, RR 5.8.5, same configs works awesomely and the device is cooler/faster then with Oreo. But still will works the same with both N/O and even Pie, not tested.
I also reinstalled Hearthstone as a high load app so I could tune the governor better for it, and up to 1490 MHz nothing is changed, and changed a bit target_loads and above_hispeed of the clocks above it so Hearthstone (and any other high load apps, or, using split screen with youtube) runs smoother/without lags and tasks like opening an app will finish faster, and also go back to a lower clock faster because of that. So, in the end it stays most of the time at lower clocks anyway, only difference is that it will jump faster when needed for less waiting time/lag.
Just to clarify, this is not suppose to waste battery, or drain it faster. As an efficiency profile the goal is to do the job you the want faster the possible, ramping up to the clocks that the jobs demands, without lags (or minimal lags) and go back to idle/lower clocks as soon as high clocks aren't needed anymore, so it don't overstay at a higher clocks then it's needed, very simple.
So, going to a high clock doesn't mean less battery life, finishing a job fast and going back to idle is the key to achieve more battery life, specially during deep sleep, when you really want your device go back to deep sleep fast, but also at any other time. Watching youtube, browsing and using low demand apps still uses the same clocks.
Also, on top of that you will spend more time USING the device instead of WAITING for it to finish a job. Battery life is very subjective, and SoT doesn't mean nothing IRL, I mean, are you spend that SoT waiting for a job to finish or to actually use the device?
081118 smartpack profile:
- target_load (no changes up to 1497600) ...1728000:89 1958400:91 2265600:95 -> ...1728000:88 1958400:90 2265600:95
- above_hispeed 20000 1190400:60000 1497600:64000 1728000:77000 1958400:84000 2265600:130000 -> 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000
- external storage read-ahead from 512 -> 2048 (because I've gone from a 8GB to a 32 GB SDCard, ADJUST YOURS ACCORDINGLY TO https://androidmodguide.blogspot.com/p/io-schedulers.html)
- cleaned unused and already default values from profile
File attached on OP.
I don't use SD card so what do I do?
razor17 said:
I don't use SD card so what do I do?
Click to expand...
Click to collapse
In that case nothing is needed, the configurations related to the absent sd card will not be applied.
Ok guys. I was wondering why my device was heating a lot more these last 2 days. Turns out both Alucard and Lazyplug were accidentally activated on 081119 profile. Turn one of them off and everything will be a lot better. Sorry for that. I will upload a new profile very soon.
edit:
101118 smartpack profile:
- Turned Alucard off, accidentally activated it with Lazyplug also enabled, not good!
- Managed to go 1 point higher on freq 1497 MHz, the 2 hotplugs enabled were messing with me trying to test this change before, also 1 point lower on the idle freq 268 MHz for smoother scrolling while still staying at freq 268 while idle. And some more high load optimizations now that I only got 1 hotplug enabled as it should always be.
- target_loads from 268800:29 ... 1497600:86 1574400:5 1728000:88 1958400:90 2265600:95 to -> 268800:28 ... 1497600:87 1574400:5 1728000:89 1958400:91 2265600:94
- above_hispeed 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000 -> 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000
- dirty_background_ratio 15 -> 10
I will give this a try. Hope it works well...
Yeah.
You know, try it and report back. I don't see any reports, so I assume is working well for people.
Any reports are welcome.
lentm said:
I will give this a try. Hope it works well...
Click to expand...
Click to collapse
Enviado de meu SM-G900M usando o Tapatalk
justjr said:
Yeah.
You know, try it and report back. I don't see any reports, so I assume is working well for people.
Any reports are welcome.
Enviado de meu SM-G900M usando o Tapatalk
Click to expand...
Click to collapse
No problems so far...greats for daily use..scrolling smoother than default..but pubg still laggy on lower res...may i know which rom are u using?