Related
Current Release: 12/20/2012(JB)/10/03/2012(GB+ICS)
Important, Please read: There are now two kernel versions starting with 8/10/2012 release, one for GB+limited ICS(no HWA) support and another for the ICS branch with HWA. Changes will be loggged separately for each kernel type. If you see no changelogs specifically for that type, then there's no release made. For example, 8/10/12 for GB is a continuation of the 3/21 release with none of the post-3/21 kernel ICS changes made.
Update 9/21/12: As of 9/21/12, jellybean is officially supported with the JB specific kernels.
First of all, I started this thread to make commenting and tracking easier for the incredikernel releases following Chad's latest release (8/15/2011).
I also wanted to make a distinction between Chad's initial kernels and the ones I've updated since that release and this is one way to do it. Initially I didn't want to do that but now I regretted not splitting sooner.
If you want the changelog for anything prior to my first kernel please refer to:
Chad's Incredikernel thread
Changelog:
11/30/2013 JB 4.3
Android 4.3 support
synced with updates from Android 4.3 Evervolv kernel
04/25/2013 ICS Sense+JB 4.2
dynamic fsync control
WiFi driver updates
Interactive governor updates - see Tinykernel
Entropy Tweaks
Netfilter updates
New sysfs location for fast charge for broader app compatibility - still compatible with latest incredicontrol
FUSE filesystem support
12/20/2012 JB 4.2 ONLY
add back governors that were removed in 12/15
12/15/2012 JB 4.2 ONLY
enabled UHID support
updated msm_fb for 4.2
12/11/2012 JB ONLY
cpufreq: enable overclocking of 1.15Ghz and 1.19Ghz
numerous interactive and ondemand governor tweaks
cpufreq: send uevent when governor changes
ondemand: boost pulse for JB's powerHAL
10/11/2012 JB ONLY
defconfig: several config changes to fix data usage not working
10/06/2012 JB ONLY
defconfig: enable conservative governor by request
10/03/2012 ICS+JB+GB
defconfig: remove rarely used governors and set max frequency to preventing booting higher than 998mhz
lower default hispeed_freq to 614Mhz
cpufreq: interactive: always limit initial speed bump to hispeed_freq
09/21/2012 ICS+JB+GB
ALL: New Interactive governor
ALL: Built with GCC 4.6 toolchain from Google
GB: interactive governor tweaked for battery
ICS+JB: interactive governor tweaked for butter
JB: genlock patched for JB support
JB: new wifi driver for compatibility with JB ROMs
08/11/2012 ICS+GB
KSM wasn't enabled as it should have been in the last build - fixed that - also nothing needs to be done to enable it on GB as it's on by default
08/10/2012 ICS ONLY
fixed data usage features for ICS
added mamarley's fastcharge USB patch to enable fastcharge without needing to unplug the charger
enabled KSM (Kernel Samepage Merging) - still need to enable in CM settings
08/10/2012 ICS+GB
added mamarley's fastcharge USB patch to enable fastcharge without needing to unplug the charger
07/07/2012 ICS ONLY
Merged in multiple driver updates to support HWA (chad0989)
Updated adreno kernel drivers to latest
added xtqta_guid - for ICS' data usage feature, also seems to have resolved stability issues
Added lazy CPU governor
Added back intellidemand
03/21/2012 ICS+GB
Added lazy CPU governor
02/26/2012 ICS+GB
Smartassv2 default governor for sure - doesn't override ramdisk settings though
new governor lagfree - balance between ondemand and interactive
new I/O scheduler SIO
tweaked deadline for better performance
removed CFQ/BFQ schedulers and smartass, conservative, and interactive govenors (still have interactiveX and smartassv2)
01/03/2012 ICS+GB
Tweak intellidemand and interactiveX governors for battery life
Add ZRAM and swap support and add script to toggle ZRAM - see bottom of OP for more info
SmartassV2 default governor again
12/26/2011 ICS+GB
Added faux123's intellidemand governor (thanks faux123!)
Added imoseyon's interactiveX governor (thanks imoseyon!)
Works on GB and ICS currently
interactiveX may not play nicely with ICS so intellidemand is default
Conservative is disabled, let me know if you need it back
12/08/2011 (Chad) ICS+GB
Added ICS support (limited)
11/27/2011 GB
Use ondemand, performance, and conservative governors from the Android Linux 3.0 kernel
Set minimum voltage back to 800 as the voltages will not go below 800 anyway. Anything lower is placebo effect. This is a hardware limitation.
11/14/2011 GB
Update OJ driver
BT fix for newer CM nightlies
WIFI module updates
Update and re-add BFQ scheduler as well as disable deadline
Ondemand is back
Fixes/Tweaks to ondemand and interactive
10/08/2011 GB
Adjusted smartassV2 parameters for 1GHz processor (originally for 500Mhz device)
10/01/2011 GB
Set smartassv2 to default governor
09/30/2011 GB
Added SmartassV2 governor
Current CPU governors as of the latest release:
SmartassV2
Ondemand
Interactive
Lagfree
Lazy
Technical doc on CPU governors (most of the ones in this kernel anyway)
https://raw.github.com/tiny4579/android_kernel_common/android-2.6.38-incredikernel/Documentation/cpu-freq/governors.txt
Update: 11/30/13 - removed link to incredikernel.com as the site has no content - fully on goo.im now
http://goo.im/devs/tiny4579/inc/kernels
Kernel Source
https://github.com/tiny4579/android_kernel_common
Here are a couple notes if you want to build this kernel from source:
Jellybean kernel branch is android-2.6.38-incredikernel-jb.
ICS kernel branch is android-2.6.38-incredikernel-ics.
Gingerbread kernel branch is android-2.6.38-incredikernel.
The config for the kernel is in arch/arm/configs/incrediblec-incredikernel_defconfig. If you want to switch branches I recommend doing a make incrediblec-incredikernel_defconfig after checking out that branch.
I use the GCC 4.4.3 toolchain for this kernel due to GCC 4.6 causing build issues.
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 9/21/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 in 10/3/12 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.
Lagfree:
Based on ondemand but with a softer CPU scaling which should help with battery life. It also seems to be very responsive (starting with 2/26)
Lazy:
Based on ondemand as well (Ezekeel is the developer of this governor). I cannot explain this too well but its apparent behavior seems to be to switch between low and high frequencies pretty evenly.
A note from Ezekeel on this governor:
"Thus I took the ondemand governor and implemented an additional parameter 'min_timeinstate' defining a minimum time the CPU will stay in a certain frequency state before it will be allowed to switch frequencies again. This way one can have a fine grained polling by setting the sampling_rate to a low value without running into problems with these fast frequency changes.
I did some extensive testing with a sampling_rate of 10000, min_timeinstate of 40000 and up_threshold of 90 and FLAC, mp3 and video playback all seem to work flawlessly. So it seems the root of the problem was indeed that the CPU does not handle fast frequency changes well.
I tested several apps and games and so far I have not found anything that this governor cannot handle. Thus I dare to say that it seems to be the superior choice over ondemand."
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.
I was wondering when lazy was gonna make it's way to aosp...
Sent from my ADR6300 using xda premium
OMG_VTEC said:
I was wondering when lazy was gonna make it's way to aosp...
Sent from my ADR6300 using xda premium
Click to expand...
Click to collapse
The name of the new governor says it all....
You just answered your own question. I took my own sweet time releasing it. It was built like 2 weeks ago. I was being lazy.
tiny4579 said:
Scripts/Mods if I think of something...
Click to expand...
Click to collapse
Tiny, this new thread is great, as is the work you and Chad have done on these kernels. Keep up the great work. Thank you.
jlokos said:
Tiny, this new thread is great, as is the work you and Chad have done on these kernels. Keep up the great work. Thank you.
Click to expand...
Click to collapse
Yeah, the old way was sloppy. Tired of it. I think this thread is cleaner than the sense one and it took me less time to write it.
To help out users (and document the probable future deviation), how about adding a tag to each kernel stating whether it works with froyo (which I believe is none), GB, ICS, or a multiple (which is only the last couple or so, I think).
Great work, by the way.
PonsAsinorem said:
To help out users (and document the probable future deviation), how about adding a tag to each kernel stating whether it works with froyo (which I believe is none), GB, ICS, or a multiple (which is only the last couple or so, I think).
Great work, by the way.
Click to expand...
Click to collapse
Done. 10char
Nice.....great work to you and Chad. Thanks.
Sent from my ADR6300 using Tapatalk
Thanks for the thread tiny, I was wondering what the benefits of the lazy governor were
I'm running my CPU at 128/806 Mhz with Lazy and it's been nice and smooth all day. Battery life has been as good or better than SA2 for me.
It also seemed to drop my ping time and increase the throughput in SpeedTest. I was getting really discouraged with ICS and >400ms ping times but I'm attributing the Lazy governor with right around 100ms ping and smoother data rates. When I switch back to the SA2 governor that I've been running for months data gets choppy again. The system itself seems smooth enough with SA2 but data has been very choppy.
Thank you to all you great developers for all your time, effort, and hard work. We really do appreciate it.
azradiohead said:
I'm running my CPU at 128/806 Mhz with Lazy and it's been nice and smooth all day. Battery life has been as good or better than SA2 for me.
It also seemed to drop my ping time and increase the throughput in SpeedTest. I was getting really discouraged with ICS and >400ms ping times but I'm attributing the Lazy governor with right around 100ms ping and smoother data rates. When I switch back to the SA2 governor that I've been running for months data gets choppy again. The system itself seems smooth enough with SA2 but data has been very choppy.
Thank you to all you great developers for all your time, effort, and hard work. We really do appreciate it.
Click to expand...
Click to collapse
The ROM/kernel/governor have no impact on data signal or speed so what you're seeing is coincidental. Network speed varies on so many factors outside of the control of the ROM or kernel. I'm glad to hear you like the new kernel and the lazy governor. I'm a fan of the dev of the lazy governor's work and run his kernel on my nexus.
My concern is that others will assume it will improve network performance and be disappointed when it doesn't.
Thank you for your compliments!
I just want to make sure I clarified this matter.
chocolate8175 said:
Thanks for the thread tiny, I was wondering what the benefits of the lazy governor were
Click to expand...
Click to collapse
I was looking around for something good that would make sense but I couldn't find anything so far.
Basically I added this governor on a whim. So far it seems to like lower frequencies even more than smartassv2 without too much sacrifice on speed. It might have better battery life. It seems smooth on Nil's Business Sense 3.5 though.
Interesting post here on smartassv2 from the developer of the lazy governor:
User:
and smartassV2 too but let him fix find the cause of the reboots before
Dev:
I will not integrate any new stuff until I have the cause for reboot problems tracked down. I will look into lulzactive, but I definitely will not include smartass since it is an inefficient governor.
Not sure why he said it was inefficient but could see no post about it.
Needless to say, I like lazy and lagfree so far. Give lazy and lagfree a try for a week and see what you think.
azradiohead said:
I'm running my CPU at 128/806 Mhz with Lazy and it's been nice and smooth all day. Battery life has been as good or better than SA2 for me.
It also seemed to drop my ping time and increase the throughput in SpeedTest. I was getting really discouraged with ICS and >400ms ping times but I'm attributing the Lazy governor with right around 100ms ping and smoother data rates. When I switch back to the SA2 governor that I've been running for months data gets choppy again. The system itself seems smooth enough with SA2 but data has been very choppy.
Thank you to all you great developers for all your time, effort, and hard work. We really do appreciate it.
Click to expand...
Click to collapse
may be placibo effect but I have noticed this too and confirmed with speedtest.
Sent from my incredible incredible.
RebelShadow said:
may be placibo effect but I have noticed this too and confirmed with speedtest.
Sent from my incredible incredible.
Click to expand...
Click to collapse
How does it fare with ondemand or lagfree? I still think its placebo. I can't test on my phone as I don't have data on the incredible.
Sent from my Galaxy Nexus using Tapatalk
Running GB and just installed the new Incredikernel, I saw no appreciable difference with data usage on Lazy, Lagfree, SAV2, Ondemand. Depending on your wireless signal, just moving your body by even a few inches could have an impact on data speeds (high frequency shadowing of transmission waves). The ping, might have some more sway by the CPU of the device if the program doesn't get as much processor in when communicating with the server, but not in the order of milliseconds (would be my though).
tiny4579 said:
I was looking around for something good that would make sense but I couldn't find anything so far.
Basically I added this governor on a whim. So far it seems to like lower frequencies even more than smartassv2 without too much sacrifice on speed. It might have better battery life. It seems smooth on Nil's Business Sense 3.5 though.
Interesting post here on smartassv2 from the developer of the lazy governor:
User:
and smartassV2 too but let him fix find the cause of the reboots before
Dev:
I will not integrate any new stuff until I have the cause for reboot problems tracked down. I will look into lulzactive, but I definitely will not include smartass since it is an inefficient governor.
Not sure why he said it was inefficient but could see no post about it.
Needless to say, I like lazy and lagfree so far. Give lazy and lagfree a try for a week and see what you think.
Click to expand...
Click to collapse
I'm using your latest GB kernel with the lazy governor on Warm TwoPointThree 3.5 rom. It is very smooth with very good battery life (undervolted).
jlokos said:
I'm using your latest GB kernel with the lazy governor on Warm TwoPointThree 3.5 rom. It is very smooth with very good battery life (undervolted).
Click to expand...
Click to collapse
Better than SAV2? I can't really comment myself but I like it so far.
Also, try to keep Sense kernel talk in the sense thread and aosp kernel talk in the AOSP thread. It makes tracking easier. But I also brought up the comment in this thread so it makes sense why you posted here.
tiny4579 said:
Better than SAV2? I can't really comment myself but I like it so far.
Also, try to keep Sense kernel talk in the sense thread and aosp kernel talk in the AOSP thread. It makes tracking easier. But I also brought up the comment in this thread so it makes sense why you posted here.
Click to expand...
Click to collapse
I have used both the GB and AOSP versions of the lazy governor. The GB version appears to make the Sense 3.5 rom smoother. As far as battery life, I haven't been able to tell if its better than SA2 since I have a much longer history with SA2. In any event, thanks for adding this governor to both versions (as I switch between the new ICS roms and Sense 3.5); it's another great choice for us to experiment with.
Could you make lulzactive possible tiny?
Sent from my DROIDX using Tapatalk
I'm currently on Zeus v7.01 with dianaV2.3+ kernel and I'm wondering what is the best combination of Governor/IO Scheduler/Voltage to obtain the most best battery life.
I'm not searching for best performance honestly, but instead a longer lasting phone. lol
I rarely play games, and smoothness is not a must for me (Nemus Launcher does the job, smoothest launcher ever!)
My current settings are:
CPU Frequency Tweaks
Max freq: 1000
Min freq: 100
DVFS enabled on boot
Voltage Tweak: -5
Governor: ondemandX
Io Scheduler: sio (Simple I/O)
You could try undervolting your phone,because i like performance and smoothness,my setup is like that:
Max CPU frequency:1300Mhz
Min CPU frequency:300Mhz
Governor:Smartassv2
I/O scheduler:deadline.
Sorry for useless stuff,but i like to share
My main agenda is to help, not gain thanks.
UniversalSS said:
You could try undervolting your phone,because i like performance and smoothness,my setup is like that:
Max CPU frequency:1300Mhz
Min CPU frequency:300Mhz
Governor:Smartassv2
I/O scheduler:deadline.
Sorry for useless stuff,but i like to share
My main agenda is to help, not gain thanks.
Click to expand...
Click to collapse
No no it's nice to share your experience!!
Might help others..
Hmm my phone is already UV... -5, if i decrease further wouldn't it be too low to cause instability?
And about IO Scheduler, i don't quite fully understand it.. which one drain least battery?
i am using 100-800 smartass2 sio and -7V without any problems.
Hi,
I'm using Co-Core 8.2 and I want to test One Power Guard to improve my battery life.
But I don't have any idea about which CPU governor and I/O scheduler to choose.
Could someone tell me which combination provides the best balance between power-save and performance?
I'm on Jelly Bean 4.1.2
NB. Cocafe recommends PegasusQ as CPU governor and either SIO/ROW for I/O scheduler but I would like to get some feedback from people already using One Power Guard.
Thanks in advance
luisblop said:
Hi,
I'm using Co-Core 8.2 and I want to test One Power Guard to improve my battery life.
But I don't have any idea about which CPU governor and I/O scheduler to choose.
Could someone tell me which combination provides the best balance between power-save and performance?
I'm on Jelly Bean 4.1.2
NB. Cocafe recommends PegasusQ as CPU governor and either SIO/ROW for I/O scheduler but I would like to get some feedback from people already using One Power Guard.
Thanks in advance
Click to expand...
Click to collapse
Pegasus and sioplus
OR
Hotplug and sioplus
DaRkRhiNe said:
Pegasus and sioplus
OR
Hotplug and sioplus
Click to expand...
Click to collapse
Thanks for the answer. I will give a try with Pegasus
However I noticed that sioplus is not available on One Power Guard settings. Only row and sio.
Is sioplus available in Co-core 8.2?
These apps like this just drains your battery. If you want play with CPU, download a CPU controller app. (like SetCPU) and install CoCore 9.0 which is newest version.
When you don't use phone ; 600 MHz Max & HotPlug
When you don't use phone V2 ; 600 MHz Max & Ondemand & deeper sleep status
When you lock phone, don't decrease speed (too much) because it will use whole CPU if it needs ; 800 MHz Max & Ondemand Q/Lulzactive Q/Pegasus Q
When using ; 1000 MHz Max & Ondemand/Interactive/Lulzactive Q/Pegasus Q
When you get mad and crazy about performance, lock the min to max; 1000 MHz min and max & Ondemand & SmartAss (still exists or not I don't know)
If you increase minimum speed it will keep it. So I suggest always keep min to 200MHz. (if exists 0 MHz I don't remember it too)
Edit: and don't go deeper sleep if you use hot plugger governors like Hotplug, Pegasus, Lulzactive Q
FYI
http://forum.xda-developers.com/showthread.php?t=2312491
Powered by CM11
Thanks guys,
I will compare the battery draining with One Power Guard just to give it a try.
If I don't notice any improvement then I will tweak with SetCPU
King ov Hell said:
Edit: and don't go deeper sleep if you use hot plugger governors like Hotplug, Pegasus, Lulzactive Q
Click to expand...
Click to collapse
Hi again,
What exactly do you mean wit "deeper sleep"?
Is that an option or when the display is off after several minutes?
Sorry for my ignorance
luisblop said:
Hi again,
What exactly do you mean wit "deeper sleep"?
Is that an option or when the display is off after several minutes?
Sorry for my ignorance
Click to expand...
Click to collapse
Go to the CoCore's thread you'll see. It's deep sleep level which can increase your battery life when you don't use the device. It's not about using, it's about when it's stand-by.
Ok
After one day even if One Power Guard is a nice app I prefer to switch governor depending on the display status. So I was thinking about using tasker (instead setCPU) which is already running on my phone and this way not adding more background processes.
I set a couple of task using the CPU control from tasker. It is working fine switching governors but I noticed that the frequencies (min and max) don't change. I tried even with shell script and still I don't get to set the max frequency. Then I prefer to make you a couple of questiosn:
-In tasker when using the CPU control. If I change governor. Should it be set in both CPUs (0 and 1) or only in a single one? In my case i set the governor in both.
-I use the terminal to check the current governor and max frequency (for instance for the cpu0)
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governorcat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
As said above the governor is succesfully changed but that's not the case for the frequency. Then I tried to run a shell script to change the max frequency as follows:
echo #frequency > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
But it seems not working neither. So I wonder if I'm doing something wrong.
NB. By the way I'm happy using the governor hotplug while not using my phone (thanks for the advice). In normal use I set pegasusq with sio and seems working great.
L.S,
I have done much research about cpu governors and io schedules, so i basically know what they do and how they affect your performance/battery.
The thing is, i can't find out which configuration suits me best. I don't need extreme performance, nor a battery which lasts a week, i'm looking for a balance between them.
And i don't know how to achieve just that, i don't know if they have a relation and how they affect each other.
Things that are of important for me:
-System stability, no crashes or reboots or freezes or whatever
-Reasonable batterylife, it'd be nice if the battery lasts the day
-Reasonable performance, i don't require a high performance device, but nothing is more frustrating than a laggy system/bad responsiveness
The available io schedules are: noop,deadline,cfq,sioplus.
available cpu governors: abysplug, userspace, performance, interactive, ondemand, conservative, powersave
If it matters, I'm currently running maclaw's CM11(20142209), probably switching to TeamCanjica's.
Thanks in advance for your efforts!
(if in the wrong section, sorry, pls move thread)
beertjen said:
L.S,
I have done much research about cpu governors and io schedules, so i basically know what they do and how they affect your performance/battery.
The thing is, i can't find out which configuration suits me best. I don't need extreme performance, nor a battery which lasts a week, i'm looking for a balance between them.
And i don't know how to achieve just that, i don't know if they have a relation and how they affect each other.
Things that are of important for me:
-System stability, no crashes or reboots or freezes or whatever
-Reasonable batterylife, it'd be nice if the battery lasts the day
-Reasonable performance, i don't require a high performance device, but nothing is more frustrating than a laggy system/bad responsiveness
The available io schedules are: noop,deadline,cfq,sioplus.
available cpu governors: abysplug, userspace, performance, interactive, ondemand, conservative, powersave
If it matters, I'm currently running maclaw's CM11(20142209), probably switching to TeamCanjica's.
Thanks in advance for your efforts!
(if in the wrong section, sorry, pls move thread)
Click to expand...
Click to collapse
Sioplus and SIO (before) was fine to me, but on latest builds it was not as before I think.
Try Interactive and Sioplus. On TeamCanjica try SIOPLUS and InteractiveQ if its there. I am on stock with CoCore and it has them, CM11 by TC should be similar o CoCore.
shut_down said:
Sioplus and SIO (before) was fine to me, but on latest builds it was not as before I think.
Try Interactive and Sioplus. On TeamCanjica try SIOPLUS and InteractiveQ if its there. I am on stock with CoCore and it has them, CM11 by TC should be similar o CoCore.
Click to expand...
Click to collapse
Thanks, i'll try this combination and see if it works. Any reason to choose interactive above ondemand?(since they are similar, i believe)
Second, does sioplus cause a less responsive system by it's slow random-reads?
Thank you for your time.
beertjen said:
Thanks, i'll try this combination and see if it works. Any reason to choose interactive above ondemand?(since they are similar, i believe)
Second, does sioplus cause a less responsive system by it's slow random-reads?
Thank you for your time.
Click to expand...
Click to collapse
My favorite was Sio+PegashusQ. Now I started to use InteractiveQ, not sure how much is it different from ondemand.
Well I did got some slowdowns on sioplus I think. Try Zen too, or any combination to see what fits you.
I on stock with cocore refresh 10 and i use ondemand + cfq (default).
No lag and good battery life.
governor
I use abbysplug and sioplus
Pegasusq + sioplus
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.