Bricked Kernel from the sensation forums, and it screams performance! I asked the dev show-p1984 if he thought about porting it our way, but said since he doesn't have a 3d it's probably not gonna happen... Maybe one of our awesome kernel devs could work with him to get it over here. Wishful thinking I guess! Anyways what do you all think of this kernel? Maybe if we can get enough interest in it, we may see it in our future!
Here's the thread: http://forum.xda-developers.com/showthread.php?t=1256668
If this is not gravy to post my bad and mods can delete!
show-p1984 said:
Bricked-Kernel v1.0
THE FIRST 2.3.4 BASED KERNEL
WITH FIXED 3D GAMING!
WORKS ON SENSE 3.5 LEAK (2.3.5 RUU)
ENJOY!
Default clocks: 1536Mhz max / 192Mhz min
OverClockable till 1890Mhz !NOT ALL DEVICES CAN HANDLE THIS!
GPU Overclock @ 300Mhz (maximum on most devices)
L2 Performance Boost only @ 1536Mhz (original by faux123)
(for stability reasons)
10000+ Downloads! I must be doing something right!
(not counted those who downloaded it with InsertCoin )
Features:
Code:
[B][U][SIZE="5"][COLOR="Red"] * FIXED 3D GAMING! YES, IT WORKS![/COLOR][/SIZE][/U][/B]
[U]*CM7 compatible version: [URL="http://forum.xda-developers.com/showthread.php?p=17697845#post17697845"]Click me[/URL][/U]
* 2.6.35.14
* based on HTCs-2.3.4-Sources
* Too many ARM optimizations to count ;)
* Built with highest Optimization Level (O3)
* Strongly improved UI-performance (Quote: "Smoother than butter")
* KGSL Early Suspend drivers (should save battery)
* KGSL Turbo Mode
* Increased 3D-Performance
* Reduced power usage, 5 stages GPU scaling!
* CIFS
* UTF8 encoding (included for CIFS)
* wifi pm=fast
* Tweaked ondemand governor (reacts a lot faster)
* Undervoltage
* Overclocking to 1536Mhz default (max. 1890Mhz)
* Min Clock @ 192Mhz default
* Synchronous Multicore Threading
* Boot time optimization. CPU will have max clocks during boot to ensure a fast bootup
* Blazing fast with InsertCoin
* added smartassv2 as optional governor
* tweaked smartassv2 to fit pyramid OC clocks
* 2D-Performance Boost
* Flashlight and Camera-Flash will now be useable until battery reaches 15%
* Tree-based preemptible RCU
* Fast scheduler for CPU hotplug
* improved 3D performance
* optimized preemptive settings
* basic NTFS support
* Userspace driven configuration filesystem
* Allow CPU-supported unaligned accesses (faster than doing it by software)
* sysfs interface for mfreq
* Scaling_Available_Frequencies in cpufreq sysfs interface
* Global CPU Voltage table used for adjusting voltage table for SnapDragon Dual Core. Inspired by Snq- modified by faux123 for SnapDragon fixed by show-p1984
* Up2date Wifi driver
* Improved Mobile Connection (fixed possible freezes introduced by HTC)
* Updated USB driver
* Let MMFPB drop to 27MHz when processor power-collapsed (by Matt Wagantall)
* hotplug notifications for CPU, L2, bus, voltage (by Matt Wagantall)
* ~8% Undervolted till 1536Mhz
* Increased Voltage for higher clocks to run stable @ 1536Mhz++
* L2 Performance Push @ 1536Mhz (Original by faux123)
* Adreno220 OC mode @ 300Mhz when max scaled (Scaling is still automatic)
* Overclock till 1890Mhz possible. ALL FREQUENCIES ABOVE 1782Mhz ARE CONSIDERED UNSTABLE!
--(I don't want to increase Voltage any further, this will increase the risk of burning your cpu. So if it is unstable, choose a lower clock!)
* Let cpu1 jump in faster. (shouldn't affect battery but decreases lag some users were experiencing)
* Tweaked ondemand to raise frequencies with higher load only (should contribute to battery life)
* removed redundant code, has led to slower performance
* Create private workqueue for cpu frequency changes, speeds up things
* Increased writing performance (lowers that annoying lag when updating 2 apps at the same time)
* added 1080p playback optimization
* Increased GPU memory
* increased overall L2 frequencies, were bottlenecking
* included call rec support, yeah that's right, you can record calls now!
* Improved WIFI - WLAN detection
* CPU temperature @ /sys/class/thermal/thermal_zone1/temp
* [url]http://stackoverflow.com/questions/4212206/about-sched-automated-per-tty-task-groups[/url]
* Lowered wifi-voltage (cayniarb)
* Updated firmware memory size (Leedroid)
* added lib: Improved the performance of memcpy and memmove of the general version (Arne Coucheron)
* USB: read/write performance & detection enhancement (Chiranjeevi, Velempati)
* cleaned code, improved performance
* Dropped debug code, was slowing things down
Changelog @ 2nd Posthttp://forum.xda-developers.com/showpost.php?p=17430308&postcount=2
How to install?
Just flash from recovery. Though it creates a boot.img out of the one on your phone while flashing, it should work with the majority of ROMs out there.
Where to complain about errors/bugs?
Please use the Issuetracker for bugs/errors/feature wishes!
Issuetracker @ https://code.google.com/p/bricked/issues/entry
[email protected]
IRC Chat: Freenode IRC #bricked
Download:
No Guarantees! If it kills your grandmother or your device, I am NOT responsible! If you understand this:
(If you download, please hit Thanks below my post! Thank you!)
*v1.0* [ondemand, smartassv2 optional, PREEMPTIBLE, recommended] Click me
EXPECT BUGS DUE TO MASSIVE CHANGES TO THE POWER MANAGEMENT!
The Camera on 2.3.5 + Sense 3.5 is currently not working, this seems to be due to missing drivers from HTC (msm cam ZLS)... Again. I am trying to bypass this.
*v.91* [ondemand, smartassv2 optional, PREEMPTIBLE, Fallback, 100% stable, not for Sense 3.5] Click me
Not all devices may run with GPU @ 320Mhz! Enthusiast version!
*v1.0* maxGPUOC [ondemand, smartassv2 optional, PREEMPTIBLE, [email protected]] Click me
*CM7 v0.1 ALPHA* [ondemand, PREEMPTIBLE] Click me calling fixed!
XDA Discussion for CM7: Click me
Current Downloads: Click Me
All Downloads: Click Me
Use System Tuner or SetCPU to overclock!
3D-Issue News:
#Fixed. By me. No-one else. Eat that.
------
Only @ gcode.
Code:
[CENTER][SIZE="6"][B][U]Donor List:[/U][/B][/SIZE]
[B][SIZE="4"][FONT="Verdana"][COLOR="Red"][U]stevejau[/U][/COLOR][/FONT][/SIZE][/B] tinky1 [B][FONT="Verdana"]ziggimon.x2 Sobat.x2[/FONT][/B] moskito-hd2 [B][FONT="Verdana"]VisedMonk.x2[/FONT][/B] smint86
[B][FONT="Verdana"][U]deagleone.x2[/U][/FONT][/B] [B][FONT="Verdana"]alhuang69.x2[/FONT][/B] thebarsteward madmarinero [U][B]Twister988[/B][/U] mwie [U][B]baadnewz[/B][/U]
auras76 vlad48 [B][COLOR="Red"][SIZE="4"][U][FONT="Verdana"]dingolino[/FONT][/U][/SIZE][/COLOR][/B] ChimeyJimmey artymarty rawrfische neuralboy
-Punisher- [U][B]Sym_Link[/B][/U] omerkisoss mweulink nbicho tinker2000 viking37
[/CENTER]
Thank you very much!
Gcode: https://code.google.com/p/bricked
Click to expand...
Click to collapse
Sent from my PG86100 using XDA App
show-p1984 said:
Changelog:
Code:
[B][U][SIZE="4"]***** v1.0 *****[/SIZE][/U][/B]
* Works with 2.3.5 (Sense 3.5 leak)
* KGSL Early Suspend drivers (saves battery & reduces heat)
* KGSL Turbo Mode
* KGSL: Turn the clocks on before the power.
* drivers: misc: pass miscdevice pointer via file private data (by Samu Onkalo
<[email protected]>)
* Fixed possible null pointer refference
* prepared for badass governor (he hasn't made it in this release :()
* Tweaked ondemand to reduce battery usage
* Tweaks for the new libs
[B][U][SIZE="4"]***** v0.91 *****[/SIZE][/U][/B]
* Changed ondemand to default again. Smartassv2 as default was not intended!
[B][U][SIZE="4"]***** v0.9 *****[/SIZE][/U][/B]
* CPU temperature @ /sys/class/thermal/thermal_zone1/temp
* http://stackoverflow.com/questions/4212206/about-sched-automated-per-tty-task-groups
* Lowered wifi-voltage (cayniarb)
* Fix scaling_cur_freq (mdeejay)
* Update firmware memory size (Leedroid)
* added cpufreq: address issue with second core forgetting min/max clock freq (Leedroid) & fixed
* added lib: Improve the performance of memcpy and memmove of the general version (Arne Coucheron)
* Lowered battery usage a bit. (Does not affect performance)
* USB: read/write performance & detection enhancement (Chiranjeevi, Velempati)
[B][U][SIZE="4"]***** v0.86 *****[/SIZE][/U][/B]
*******************************
**RC1 Release of v0.9 - If a newer version comes out, I recommend to upgrade immediately!
**This will wipe your /cache! You do not need to do it yourself!
*******************************
Changes from v0.8: (mostly improving my 3D Games Fix)
* this should finally fix these annoying sleep reboots some ppl were experiencing
* improved overall performance
* Highly optimized kernel build (O3), this should bring an additional performance boost
* cleaned code
* Combines the speed and stability of 0.7 with the 3D performance and 3D-fix from 0.8
* Fixed performance drops
* Fixed deep-sleep reboot
* Fixed 2 additional GPU scaling bugs that would have prevented the system from falling into deep-sleep mode
* Reenabled dynamic powercontrol (my fault -.-)
* Tweaked performance on one or two edges ;)
* improved stability (show, you should check pointer...)
* Fixed ioctl errors
* Fixed widget bugs (I couldn't reproduce them anymore)
* Fixed a GPU scaling bug, phone should stay cooler now
--caused the GPU to get stuck at maximum frequency
[B][U][SIZE="4"]***** v0.8 *****[/SIZE][/U][/B]
**********************************************************
***[B][U][COLOR="Red"]FIXED 3D BUG! FIRST 2.3.4 BASED KERNEL WITH FIXED 3D![/COLOR][/U][/B]***
**********************************************************
* rewrote GPU scaling
* overclock of Adreno220 reduced to 300Mhz
(was causing problems on some phones)
[B][U][SIZE="4"]***** v0.7 *****[/SIZE][/U][/B]
* Included a thermald.conf file in install.zip (fixes reboots)
* cleanups
* modified GPU scaling
* modified GPU pwr_levels
* increased Adreno220 OC mode to 320Mhz when max scaled (again, now it is working)
[B][U][SIZE="4"]***** v0.6 - HOTFIX1 *****[/SIZE][/U][/B]
* lowered Adreno220 OC mode to 300Mhz when max scaled (Scaling is still automatic)
[B][U][SIZE="4"]***** v0.6 *****[/SIZE][/U][/B]
* Adreno220 OC mode @ 320Mhz when max scaled (Scaling is still automatic)
* Overclock till 1890Mhz possible now. ALL FREQUENCIES ABOVE 1782Mhz ARE CONSIDERED UNSTABLE! (I don't want to increase Voltage any further, this will increase the risk of burning your cpu. So if it is unstable, choose a lower clock!)
* Tweaked ondemand yet again to let cpu1 jump in faster. (shouldn't affect battery but decreases lags some users were experiencing)
* Tweaked ondemand to raise frequencies with higher load only (should contribute to battery life)
* removed redundant code, has led to slower performance
* Create private workqueue for cpu frequency changes, should speed up things
* Increased writing performance (should lower that annoying lag when updating 2 apps at the same time)
* Changed Smartassv2 to compile as module. Makes it easier to offer different versions.
* added 1080p playback optimization
* Increased GPU memory
* increased overall L2 frequencies, were bottlenecking
* included call rec support, yeah that's right, you can record calls now!
* Improved WIFI - WLAN detection
* Allow CPU-supported unaligned accesses (faster than doing it by software)
* Add sysfs interface for mfreq
* Added Scaling_Available_Frequencies to cpufreq sysfs interface
* Added Global CPU Voltage table used for adjusting voltage table for SnapDragon Dual Core. Inspired by Snq- modified by faux123 for SnapDragon fixed by show-p1984
[B][U][SIZE="4"]***** v0.5 *****[/SIZE][/U][/B]
* [B]Updated Kernel base to 2.6.35.14[/B]
--( 247 changed files with 1,846 additions and 754 deletions )
* Tweaked preemptive settings
* Added NTFS support
* Added Userspace driven configuration filesystem
* Updated Wifi driver
* Improved Mobile Connection (fixed possible freezes)
* Updated USB driver
* Let MMFPB drop to 27MHz when processor power-collapsed (by Matt Wagantall)
* Use hotplug notifications for CPU, L2, bus, voltage (by Matt Wagantall)
* [B]8% Undervolted till 1536Mhz (again)[/B]
* [B]Increased Voltage for higher clocks to run stable @ 1536Mhz++[/B]
* [B] Added OC till 1782Mhz.[/B]
* [B]Added L2 Performance Push @ 1536Mhz (Original by faux123)[/B]
* Cleaned ACPU Table frequencies
[B][U][SIZE="4"]***** v0.4 *****[/SIZE][/U][/B]
* Tweaked ondemand to preserve battery
* Tweaked ondemand to react faster
* 2D-Performance Boost
* Flashlight and Camera-Flash should now be useable until battery reaches 15%
* Tree-based preemtible RCU
* Fast scheduler for CPU hotplug
* +84 Insertions regarding 3D performance
[B][U][SIZE="4"]***** v0.3 *****[/SIZE][/U][/B]
* more optimizations
* added smartassv2 as optional governor
* tweaked smartassv2 to fit pyramid OC clocks
* further ondemand governor tweaks (should be as fast as before with a little less power consumption)
* changed max clock to 1536Mhz (1538 was a typo -_-)
* cleaned ACPU table frequencies
* fixed an issue where CPU1 would fall back to userspace governor
[B][U][SIZE="4"]***** v0.2 *****[/SIZE][/U][/B]
* 2.6.35.13
* based on HTCs-2.3.4-Sources
* Too many ARM optimizations to count ;)
* CIFS
* UTF8 encoding (included for CIFS)
* wifi pm=fast
* Tweaked ondemand governor (should react a lot faster, but can't predict battery usage yet)
* Undervoltage
* Overclocking to 1538Mhz default (this makes more sense than 1512)
* Min Clock @ 192Mhz default
* Synchronous Multicore Threading
* Boot time optimization. CPU will have max clocks during boot to ensure a fast bootup
* Blazing fast with IC2.4.2/3
* Should work with every ROM since the boot.img is generated while flashing.
What does PREEMPTIBLE mean:
Preemptive built kernels are favoring the userinterface over everything else! That means: An app in the background is using 50% of you CPU to spy on you. You want to move fast through the user interface/watch a video, whatever. The kernel will now favor your action over the app in the background. That's all the magic that's happening
-------------
-----------------------------
-------------
Benchmarks:
Click Me for Benchmark
How to Overclock CPU1 (this is not supported by all OC apps):
Overclocking the second CPU is currently not supported by many apps. (They can't overclock what they can't see, aSMP)
To enforce this with Bricked:
Code:
echo 1 > /sys/devices/system/cpu/cpu1/online
echo 1782000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
CPU1 will shutdown after it is sure that it is not needed anymore. But you can also do:
Code:
echo 0 > /sys/devices/system/cpu/cpu1/online
Right after the both commands above. Then CPU1 will fall asleep.
Battery theme as seen in the screenshots, and some other stuff:
http://forum.xda-developers.com/showpost.php?p=17336120&postcount=5186
(still works with InsertCoin 2.4.3)
Click to expand...
Click to collapse
Sent from my PG86100 using XDA App
Sent from my PG86100 using XDA App
"Expect bugs due to massive changes in power management"?
No thanks, I'll pass.
The name doesn't inspire a lot of confidence either!
Sent from my PG86100 using XDA Premium App
we need BFS
Looks nice... Don't like name but interested either way... 320mhz gpu...(what is stock MHz)
Sent from my PG86100 using xda premium
There is a lot going on there, I'll read the original thread to see how they like it.
Tilde88 said:
we need BFS
Click to expand...
Click to collapse
Why? CFS runs better on the phone.
Tilde88 said:
we need BFS
Click to expand...
Click to collapse
No we don't.
Our gpu can be over clicked?! We need this! Haha
Sent from my HTC Evo 3D.
did it's work for evo 3d gsm
Tilde88 said:
we need BFS
Click to expand...
Click to collapse
CFS is so much more stable than BFS. We definitely do not need BFS.
OK, after looking over the last couple pages of the original thread.... I want this kernel.
Most these tweaks should be completely possible as both phones use the same CPU.
felacio said:
OK, after looking over the last couple pages of the original thread.... I want this kernel.
Most these tweaks should be completely possible as both phones use the same CPU.
Click to expand...
Click to collapse
Exactly! I would love to see our gpu overclocked
Sent from my PG86100 using XDA App
I ask CdTDroiD in the Pyramid3D thread (General Sec.), will the Bricked kernel be included in the rom, due to the fact it being the default kernel for that rom on the sensation. I guess the developer has to make a version for the 3D. It's still fairly early in development for this device so I could see it happening.
私の"DU4L C0R3 SH00T3Rは"³Dであなたを撃墜！トゥパックをねじ込みます 。
"AOSPのBACK!" ┌П┐[◣_◢]┌П┐
r0cky0790 said:
I ask CdTDroiD in the Pyramid3D thread (General Sec.), will the Bricked kernel be included in the rom, due to the fact it being the default kernel for that rom on the sensation. I guess the developer has to make a version for the 3D. It's still fairly early in development for this device so I could see it happening.
私の"DU4L C0R3 SH00T3Rは"³Dであなたを撃墜！トゥパックをねじ込みます 。
"AOSPのBACK!" ┌П┐[◣_◢]┌П┐
Click to expand...
Click to collapse
I asked the dev in the bricked thread and he seemed like he would but his only concern was testing since he does not have a 3d... that's why I was hoping someone with kernel experience with a 3d could work with him and maybe port it over here. Obviously if there was a kernel on our end willing to, we would need his concent. Who knows but I would imagine sooner or later we will see those features since out phones are so similar.
Sent from my PG86100 using XDA App
Dude this kernel sounds like pure awesomeness, i want it in my 3d.
We need to get every dev aware if this!!!
Kernels for the EVO3D have been a problem. It doesn't seem like anyone wants to help us out. They will make one then leave for months and never look back. I started looking into it and made some progress but by no means gonna be a master of it. Its kind of a shame.
If Net would come back he could likely knock this out for us since he got donated that evo3d.
And by come back I mean developing. Sad haven't seen anything new from him in a long time. Hope everything is alright.
Sent from my PG86100 using XDA App
did it work on gsm 3d evo on 2.3.4 sense 3.0 ?
photpix said:
did it work on gsm 3d evo on 2.3.4 sense 3.0 ?
Click to expand...
Click to collapse
No, its currently a kernel for the sensation.
Sent from my PG86100 using XDA App
Related
Diet Android Kernel 2.6.33.2 by PsyQ
I am releasing the kernel which I use by myself I removed most of the debugging options useful for kernel/driver debugging and maxed-out possible compiler optimizations. It has Hybrid AVS support using IntersectRaven's improved method as well as optional overclocking (see note)
These kernels feature:
* Hybrid Adaptive Voltage Scaling for extra battery life
* Optional 1.1 GHz Overclocking Support
* Extra 8 MB of RAM reclaimed from Camera
* Based on Cyanogen's 5.0.6 kernel
* Maximum possible compiler optimizations (loop unrolling, tree vectorization, NEON, Cortex A8 compiler tuning, armv7a target, and many more)
* Removed all unnecessary features from the kernel configuration, including debugging options (these kernels are not useful for kernel debugging / driver development)
* All cpufreq governors (ondemand, powersave, conservative, ...) for people that want to tweak the CPU frequency scaling
Following kernels are available:
diet_2.6.33.3.hybrid_avs_800mv.zip --> Hybrid AVS support, goes down to 0.8 volts and has stock frequency (998 MHz) as max.
diet_2.6.33.3.hybrid_avs_800mv_OC.zip--> EXPERIMENTAL Hybrid AVS with overclocking to 1.1 GHz (0.8v min voltage)
diet_2.6.33.3.hybrid_avs_925mv.zip --> Hybrid AVS support, goes down to 0.925 volts and has stock frequency (998 MHz) as max.
diet_2.6.33.3.hybrid_avs_925mv_OC.zip--> EXPERIMENTAL Hybrid AVS with overclocking to 1.1 GHz. (0.925v min voltage)
To use it, flash the zimage with fastboot and push the bcm4329.ko to the /system/lib/modules:
Code:
[power off your phone and boot into fastboot]
fastboot flash zimage zImage
[reboot]
adb remount
adb push bcm4329.ko /system/lib/modules/bcm4329.ko
Pushing of the bcm4329.ko is necessary as WiFi support would be broken otherwise. If you don't do it, WiFi will not work.
Changelog:
Code:
V1.11 - Update - May/02nd/2010
- Moved to 2.6.33.3 Kernel
V1.10 - Update - Apr/26th/2010
- Changed floating point model to VFP
- There are two AVS versions with different lowest voltage limits (800/925mv)
V1.09 - Update
- Implemented IntersectRaven's Hybrid AVS method
- Synced with the latest code snapshot of CM kernel
V1.08 - Update
- Non AVS kernel is now undervolted down to 0.925v
- Kernel RCU is now of uniprocessor type, saving memory
- DMA speedup patch from latest CM source
- Removed "loopback" file device (this is not related to network)
- Further compiler optimizations
V1.07 - Update
- 8 MB RAM reclaimed from Camera
- Further kernel trimming
- AVS is now available with 0.925v and 0.850v flavors
- Some attempts to make AVS more stable (still work in progress)
V1.06 - Update
- Moved to kernel 2.6.33.2 from Cyanogen's 5.0.5.6 source
- AVS kernels are capable of undervolting down to 0.925v instead of 1.000v
- Minor cleanups
V1.05 - Update
- Further fixes in AVS Support (thx intersectRaven!)
V1.04 - Update
- Fixed bugs in AVS Support
- More kernel tweaks
- Removed "normal" version of the kernel, as _xtra seems to be stable enough
- Added non-overclocked AVS kernel for maximum battery life
V1.03 - Update
- Added Experimental Adaptive Voltage Support (AVS)
- Currently AVS is "for test only", and this kernel has debug support and no loop unrolling
V1.02 - Update
- Switched to CFQ I/O Scheduler
- Removed some more stuff (e.g. 10 Gbit Ethernet Support)
V1.01 - Update
- Added Conservative Governor
- Fixed table lookup bug (thanks pershoot!)
V1.0 - Initial Release
- Based on CyanogenMod 5.0.5.3 source
- Overclocking Support (1.1 GHz)
- Undervolted
- Optional extra undervolt (see attachments - _xtra is additional UV)
- Added Powersave CPU governor
- Removed most of the debugging stuff from Kernel (which makes this kernel useless for kernel debugging!)
- Even more C compiler optimizations (almost -O3 level + extra stuff, like loop unrolling, etc...)
- Audioboost patch
For other kernel developers - you can find the source code here (note that for AVS support you need AVS sources from ChromeOS):
http://github.com/psyq321/nexus_one_kernel_additions
Do you use the xtra version, if so have you noticed any problems
Nice release, will definitely try sometime.
Grrr!!! checked for updated version right before leaving for work, and just missed it!
I am using the one you posted in the other forum without any issues. Does it possess the same undervolting as the Xtra version?
Yes, _xtra is using same undervolt as the version from yesterday.
Additionally, this version contains more optimizations (loop unrolling) that I managed to cram-in by removing more debug options of the kernel (otherwise it would not fit)
What is loop unrolling?
Awesome, I'll pull the config to see what you have done...
just installed on my device. so far so good, using the extra undervolt. booted fine and everything so will report back later if I notice anything weird.
Hi man, in first thanks for this work...
Now can u tell me how can i use your kernel?
Thanks in advanced
just
[power off your phone and boot into fastboot]
fastboot flash zimage zImage
[reboot]
adb remount
adb push bcm4329.ko system/lib/modules/bcm4329.ko
interesting...I've been experimenting with the compiler optimizations in my own build...it made the kernel bigger although I feel a bit more responsiveness now...almost not noticeable but I think its there...
xPatriicK said:
What is loop unrolling?
Click to expand...
Click to collapse
Loop unrolling is the optimization technique used by modern compilers to potentially speed-up execution by decreasing overhead of the loop passes.
For example, imagine that you have a loop, that does something 4 times:
Code:
for(x=0; x<4; x++) {
do_something;
}
In this case, some % of the execution will be checking if the x is less than 4, and if no - "doing_something" again. This check has to be performed for every step (so, it is done 4 times)
Now, if you unroll this loop, it would look like this:
Code:
do_something; x++;
do_something; x++;
do_something; x++;
do_something; x++;
^ So, in this case, we completely eliminated checks.
Or, if the loop is much bigger (say, x goes up to 800):
Code:
for(x=0; x<800; x+=4) {
do_something;
do_something[x+1];
do_something[x+2];
do_something[x+3];
}
See? In this case, you reduce the number of condition checks for bigger loops.
This can sometimes make code faster - but the downside is that it makes the code bigger (which is obvious even in those examples above).
In Android Kernel 2.6.33.1 case - loop unrolling increases zImage size by ~350K. If I didn't strip debugging stuff out, zImage would be too big to fit on Nexus One.
Fortunately, there was approx. 400K to be saved by just kicking out features that enable kernel debugging. I don't think most of the people need that. These features are useful for kernel and driver developers, but most of others can perfectly live without them
Alright, thank you!
will try _xtra when Paul released the new Desire cam. Thanks for your work
Ivan Dimkovic said:
Loop unrolling is the optimization technique used by modern compilers to potentially speed-up execution by decreasing overhead of the loop passes.
For example, imagine that you have a loop, that does something 4 times:
Code:
for(x=0; x<4; x++) {
do_something;
}
In this case, some % of the execution will be checking if the x is less than 4, and if no - "doing_something" again. This check has to be performed for every step (so, it is done 4 times)
Now, if you unroll this loop, it would look like this:
Code:
do_something; x++;
do_something; x++;
do_something; x++;
do_something; x++;
^ So, in this case, we completely eliminated checks.
Or, if the loop is much bigger (say, x goes up to 800):
Code:
for(x=0; x<800; x+=4) {
do_something;
do_something[x+1];
do_something[x+2];
do_something[x+3];
}
See? In this case, you reduce the number of condition checks for bigger loops.
This can sometimes make code faster - but the downside is that it makes the code bigger (which is obvious even in those examples above).
In Android Kernel 2.6.33.1 case - loop unrolling increases zImage size by ~350K. If I didn't strip debugging stuff out, zImage would be too big to fit on Nexus One.
Fortunately, there was approx. 400K to be saved by just kicking out features that enable kernel debugging. I don't think most of the people need that. These features are useful for kernel and driver developers, but most of others can perfectly live without them
Click to expand...
Click to collapse
on point. i like what i see. i will try this out.
If I use the powersave governor option, SetCPU always show it running at minimum 245MHz. Is it working as expected?
bethedealer said:
If I use the powersave governor option, SetCPU always show it running at minimum 245MHz. Is it working as expected?
Click to expand...
Click to collapse
That's fine since the powersave governor clocks it to the lowest for maximum power savings.
standby 245/245 governor is better than on demand?
xPatriicK said:
standby 245/245 governor is better than on demand?
Click to expand...
Click to collapse
Curious about this too!
xPatriicK said:
standby 245/245 governor is better than on demand?
Click to expand...
Click to collapse
It's not necessarily better. It depends on what you're optimizing for. For example, powersave governor optimizes for power savings in return for slowest clock speed which may be apparent when using CPU intensive apps. Ondemand tries to balance it somewhat while giving more importance to CPU speed since it clocks the CPU back to full speed whenever an app runs and downclocking when appropriate. The conservative governor I use in my kernel also tries to balance this but gives more importance to power savings since when an app runs it slowly ramps up the clock speed until the app finishes. Hope this clears it up!
Note that powersave might actually consume more power at the end if you do some intensive work.
Why? Because it will force CPU to stay at the lower clock, even if the task could be completet much quicker with the higher clock.
At the end - it could very well be that running the task quicker @higher clock speed could consume less power total!
Unfortunately, there is no easy way to test what is better, unless someone writes a script that performs some tasks repeatedly until battery dies, and compares the baterry life between different CPU scaling strategies.
I'd definitely not use powersave governor. Rather, I'd play with the "up threshold" and "profiles" in SetCPU to make the CPU frequency scaling more conservative.
I pooled together information on cpu governors and I/O schedulers from several sources. If anyone has any additional information to add, feel free to chime in . Credit goes to Knzo, Pikachu01, HipKat, and Droidphile for this compilation. This will continue to expand as I come across more information.
Apps are the probably the most popular methods for controlling these settings. I won't list them all, but here are the most common:
Voltage Control - I find this to be the best option; its "set at boot" method is faster and more reliable (init.d script created by the app). Doesn't have a widget that I find useful, but has everything SetCPU has and then some (I/O scheduler, GPU control, charging current, etc.)
SetCPU - limited to governors, voltages, sampling rate, etc. but has a very useful widget. I've experienced issues before with it successfully setting values at boot.
*Interested in jumping to a particular governor/scheduler/term? Press Ctrl + F and enter the term.
Post 1 - Governors
Post 2 - I/O Schedulers
Governors
knzo said:
. . .
So, what's a governor?
Code:
Consider a CPU, the processor of Optimus Black. Well, this CPU operates at
different frequencies (on stock: 300, 600, 800 and 1000 Mhz) and we usually
say it's a 1 Ghz (1000 Mhz) processor because that's the max frequency it
can go 100% stable.
Now, a governor is a CPUFreq driver. Like the name suggests, it is what
decides when to be on full speed at max frequency or when to be at min
or mid and how fast should it reach the max/min, should it be almost insta
and provide a good smoothness overall? Should it take longer and go 200
Mhz at a time and preserve battery? This and more is what a governor is.
There are many governors around, some for single-cores, some for dual-cores which I won't even refer to (jRCU). In stock you can find 5 governors, in Quasar kernel you can find much more. Most android and xda users don't even know half of governors I'll list as there is no android kernel out there with more governors than Quasar, only one has the same amount and this is a kernel made by my friend and fellow portuguese franciscofranco.
Listing of knzo-known governors:
Ondemand *&
Powersave *@
Userspace *
Conservative *
Performance *
Interactive +
InteractiveX +
Smartass +
Smoothass +
BrazilianWax +
SavagedZen +
Minmax +&
Scary +
Legend: & - default | @ - disabled by default | * - exists in stock kernel | + - added in Quasar kernel
And now the official summary for each and brief comment by myself:
Ondemand:
Code:
/*
* drivers/cpufreq/cpufreq_ondemand.c
*
* Copyright (C) 2001 Russell King
* (C) 2003 Venkatesh Pallipadi <[email protected]>.
* Jun Nakajima <[email protected]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
Ondemand is the default choice due to its balanced settings which offers a good compromise between battery and performance. However, it has no suspend profiles and falls a bit short on performance in smartphones.
Powersave:
Code:
/*
* linux/drivers/cpufreq/cpufreq_powersave.c
*
* Copyright (C) 2002 - 2003 Dominik Brodowski <[email protected]>
*
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
*/
Powersave sets the max frequency at the same clock as the min frequency. Impossible for daily usage for obvious reasons. Used usually with SetCPU screen-off profiles in combo with Ondemand.
Userspace:
Code:
/*
* linux/drivers/cpufreq/cpufreq_userspace.c
*
* Copyright (C) 2001 Russell King
* (C) 2002 - 2004 Dominik Brodowski <[email protected]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
*/
Userspace lets you manually set the frequencies. To be completely honest, I've never used it and I've never heard of anyone who uses it. I'm completely off on how it fares or if it even works or any of its kinks.
Conservative:
Code:
/*
* drivers/cpufreq/cpufreq_conservative.c
*
* Copyright (C) 2001 Russell King
* (C) 2003 Venkatesh Pallipadi <[email protected]>.
* Jun Nakajima <[email protected]>
* (C) 2009 Alexander Clouter <[email protected]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
Conservative is a slower Ondemand when it comes to ramping. For example, when you turn on the phone and start interacting with it, Ondemand will increase frequency until it reaches max at x speed. Conservative will do the same at x/2. Faster the ramping the more battery it consumes so conservative while a worse governor for performance it's also a good one for battery.
Performance:
Code:
/*
* linux/drivers/cpufreq/cpufreq_performance.c
*
* Copyright (C) 2002 - 2003 Dominik Brodowski <[email protected]>
*
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
*/
If Powersave governor is Yin, this one is Yang. It sets the min frequency the same as max frequency so the phone is always at max power. This is usually used with SetCPU profiles for when charging or plugged to computer. For obvious reasons can't be used in daily usage.
Interactive:
Code:
/*
* drivers/cpufreq/cpufreq_interactive.c
*
* Copyright (C) 2010 Google, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
* may be copied, distributed, and modified under those terms.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* Author: Mike Chan ([email protected])
*
*/
While Conservative is a slower Ondemand, Interactive is a faster one. Ramping will be slightly faster so interaction will seem more snappy with battery comsumption just increasing a tiny bit. This has been the most popular governor for the past year.
InteractiveX:
Code:
/*
* drivers/cpufreq/cpufreq_interactive.c
*
* Copyright (C) 2010 Google, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
* may be copied, distributed, and modified under those terms.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* Author: Mike Chan ([email protected]) - modified for suspend/wake by imoseyon
*
*/
As you can see in the summary, this is Interactive with some modifications by imoseyon. Now instead of using the dirty SetCPU profiles method of locking the frequency to minimum when phone is asleep, the own governor will do that which is a cleaner method and with a better ramping management when coming out of sleep. Basically, it has Interactive's performance with better battery.
Smartass:
Code:
/*
* drivers/cpufreq/cpufreq_smartass2.c
*
* Copyright (C) 2010 Google, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
* may be copied, distributed, and modified under those terms.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* Author: Erasmux
*
* Based on the interactive governor By Mike Chan ([email protected])
* which was adaptated to 2.6.29 kernel by Nadlabak ([email protected])
*
* SMP support based on mod by faux123
*
* requires to add
* EXPORT_SYMBOL_GPL(nr_running);
* at the end of kernel/sched.c
*
*/
This one has been increasingly popular and it's becoming the favorite one for Q3-4 2011. Smartass is based on Interactive but with some modifications, as well as built-in profiles. Recently, Erasmux released this v2 which by what people are saying it's very good. I suggest you go to this link for more informations. It's probably Quasar's best governor at the moment, along with Minmax.
Smoothass:
Code:
/*
* drivers/cpufreq/cpufreq_smoothass.c
*
* Copyright (C) 2010 Google, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
* may be copied, distributed, and modified under those terms.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* Author: Erasmux
*
* Based on the interactive governor By Mike Chan ([email protected])
* which was adaptated to 2.6.29 kernel by Nadlabak ([email protected])
*
* requires to add
* EXPORT_SYMBOL_GPL(nr_running);
* at the end of kernel/sched.c
*
*/
One more jewel from Erasmux. As far as I know this is a Smartass v1 tuned for a more aggressive ramping, which means, more performance and snappiness, less battery.
BrazilianWax:
Code:
/*
* drivers/cpufreq/cpufreq_brazilianwax.c
*
* Copyright (C) 2010 Google, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
* may be copied, distributed, and modified under those terms.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* Author: Erasmux
*
* Based on the interactive governor By Mike Chan ([email protected])
* which was adaptated to 2.6.29 kernel by Nadlabak ([email protected])
*
* requires to add
* EXPORT_SYMBOL_GPL(nr_running);
* at the end of kernel/sched.c
*
*/
Someone correct me if I'm wrong but this is basically the same as Smoothass.
SavagedZen:
Code:
/*
* drivers/cpufreq/cpufreq_savagedzen.c
*
* Copyright (C) 2010 Google, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
* may be copied, distributed, and modified under those terms.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* Author: Joshua Seidel
* Based on the smartass governor by Erasmux
*
* Based on the interactive governor By Mike Chan ([email protected])
* which was adaptated to 2.6.29 kernel by Nadlabak ([email protected])
* --Modifications by arescode--
* adapted to stock (1 GHz) frequency by zacharias.maladroit
*
* requires to add
* EXPORT_SYMBOL_GPL(nr_running);
* at the end of kernel/sched.c
*
*/
Another Smartass-based kernel with many modifications aiming to attain both better battery and performance. And it succeeds in my opinion. I've used it in past devices, it's a very good overall governor, a balanced option.
Minmax:
Code:
/*
* drivers/cpufreq/cpufreq_minmax.c
*
* Copyright (C) 2001 Russell King
* (C) 2003 Venkatesh Pallipadi <[email protected]>.
* Jun Nakajima <[email protected]>
* (C) 2004 Alexander Clouter <[email protected]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
* This governor is an adapatation of the conservative governor.
* See the Documentation/cpu-freq/governors.txt for more information.
*
* Adapatation from conservative by Erasmux.
*/
This governor was a very pleasant surprise. Although an adaptation of Conservative governor it has probably the best performance of them all. Might fall shorter on battery than Smartass v2 but I owe it my best experiences in terms of snappiness so far, reason why I selected it as default governor for Nova. My personal favorite until I can draw a conclusion from using Smartass v2.
Scary:
Code:
/*
Scary governor based off of conservatives source with some
of smartasses features
For devs - If you're going to port this driver to other devices,
make sure to edit the default sleep frequencies & prev frequencies
or else you might be going outside your devices hardware limits.
*/
This is just a weird governor. It's based on Conservative which has a slower ramping than Ondemand but then again it has Smartass elements which is a governor with one the fastest rampings. I've heard some people like it but alas I never tried it myself.
Click to expand...
Click to collapse
droidphile said:
. . .
lazy:
Basically and ondemand with an additional parameter min_time_state which specifies the minimum time cpu stays on a frequency before scaling up/down. Idea here is to eliminate instabilities caused by fast frequency switching of ondemand. lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step. Lazy also has a screenoff_maxfreq parameter which can be configured to specifiy max frequency while screen is off.
lulzactive:
Based on interactive & smartass governors, this governor tends to be the new favorite for many of us. When workload is greater than or equal to 60%, the governor scales up cpu to next higher step. When workload is less than 60%, governor scales down cpu to next lower step. On screen off, frequency is locked to global scaling minimum frequency.
lagfree:
Similar to ondemand. Difference is optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree doesn't skip frequencies while scaling up or down.
smartassV2:
Modified smartass and one of the favorite governor for many a people. This governor scales down cpu very fast while screen is off and scales up to 500 mhz quickly when screen is on. There's no upper limit for frequency while screen is off. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. Thus ensuring a balance between performance and battery.
ondemandx:
Basically an ondemand with suspend/wake profile. This governor is a battery friendly ondemand. When screen is off, max frequency is 500 mhz.
. . .
Click to expand...
Click to collapse
droidphile said:
. . .
intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). 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' (rather 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. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of cpu. Lower idling time (<20%) causes cpu to scale-up from current frequency. Frequency scale-down happens at steps=5% of current frequency. (This parameter is tunable only in conservative, among the popular governors )
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is not busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
lionheart:
Lionheart is a tweaked conservative governor from Knzo. You can simply modify conservative to experience lionheart. Set low up-threshold (60 or something) and lowest possible sampling rate on conservative. Lionheart's motto is extreme responsiveness and performance, at the cost of battery. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand. This could be the reason for lionheart's 'birth'.
. . .
Click to expand...
Click to collapse
HipKat said:
Hotplug Governor:
The “hotplug” governor scales CPU frequency based on load, similar to “ondemand”. It scales up to the highest frequency when “up_threshold” is crossed and scales down one frequency at a time when “down_threshold” is crossed. Unlike those governors, target frequencies are determined by directly accessing the CPUfreq frequency table, instead of taking some percentage of maximum available frequency.
Click to expand...
Click to collapse
Information on the Pegasusq governor
robertobsc said:
LulzactiveQ
I was decided to optimize Lulzactive governor by including the dec_cpu_load parameter.
----
I was going to put it because if the inc_cpu_load is setted at a high value (example: 90%) and the pump_down_steps is also setted high (2 or 3 steps down if load < inc_cpu_load) it would happen a problem:
Suppose the current load is between 80 and 89% all the sampling rate and the pum_down_steps is 2 or 3. Do you think is a good idea to go down 2/3 steps in the load at that high?
This is not a theorical issue, i really felt lag when playing some simple games and my conclusion was that situation was happening in that moment.
Thats why i created dec_cpu_load, in this way we can tell the governor exactly when go down pump_down_steps.
----
I also fixed a little bug as well that the up_sample_time and down_sample_time wasnt been respected (the governor was scaling up and down as soon as the load criteria was matched).
-----
And i added as gokhan requested, the hotplug parameters from pegasusq. So now we have two governors with hotplug queue logic.
To the hotplug part i had to create another sample rate. The name is hotplug_sample_rate. I created that to make the hotplug part completely independent from scale up / down frequencies part. In fact, they are running in different threads.
-----
That's it. I also putted some logs that can be enabled / disabled by the dvfs_debug parameter.
If do you think something was wrong, or a problem apperead please enable this parameter for a while and execute this command in terminal emulator or adb:
dmesg > /sdcard/lulzactiveq.log.txt
----------------------
This is only a battery profile suggestion for the 16 steps. Please explore it!!!!!!
-- Parâmetros Lulzactive
echo "90" > /sys/devices/system/cpu/cpufreq/lulzactiveq/inc_cpu_load
echo "40" > /sys/devices/system/cpu/cpufreq/lulzactiveq/dec_cpu_load
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactiveq/pump_up_step
echo "2" > /sys/devices/system/cpu/cpufreq/lulzactiveq/pump_down_step
echo "50000" > /sys/devices/system/cpu/cpufreq/lulzactiveq/up_sample_time
echo "25000" > /sys/devices/system/cpu/cpufreq/lulzactiveq/down_sample_time
echo "14" > /sys/devices/system/cpu/cpufreq/lulzactiveq/screen_off_min_step
-- Lulzactive - Hotplug Queue parameters
echo "50000" > /sys/devices/system/cpu/cpufreq/lulzactiveq/hotplug_sample_rate
echo "13" > /sys/devices/system/cpu/cpufreq/lulzactiveq/cpu_up_rate
echo "13" > /sys/devices/system/cpu/cpufreq/lulzactiveq/cpu_down_rate
echo "600000" > /sys/devices/system/cpu/cpufreq/lulzactiveq/hotplug_freq_1_1
echo "400000" > /sys/devices/system/cpu/cpufreq/lulzactiveq/hotplug_freq_2_0
echo "350" > /sys/devices/system/cpu/cpufreq/lulzactiveq/hotplug_rq_1_1
echo "300" > /sys/devices/system/cpu/cpufreq/lulzactiveq/hotplug_rq_2_0
echo "0" > /sys/devices/system/cpu/cpufreq/lulzactiveq/hotplug_lock
-- debug on/off
echo "0" > /sys/devices/system/cpu/cpufreq/lulzactiveq/debug_mode
Click to expand...
Click to collapse
I/O Schedulers
Every I/O scheduler except Anticipatory has explanations from two perspectives. At the end of the post is a discussion of benchmarking and a brief comparison.
knzo said:
. . .
So, what's a I/O Scheduler?
Code:
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 minimize time wasted by hard disk seeks.
- To prioritize 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.
There is not so much offer when it comes to I/O Schedulers and the improvements aren't nearly as visible as choosing a gung ho governor but trust me they are there. Just to name one improvement you could see is for example the opening and closing of applications.
Listing of knzo-known I/O Schedulers:
Noop *
Anticipatory *@+
CFQ *&
Deadline *@+
VR +
Simple +&
BFQ #
Legend: & - default | @ - disabled by default | * - exists in stock kernel | + - added in Quasar kernel | # - not included in Quasar kernel
And now a summary for each and brief comment by myself:
Noop:
Code:
The NOOP scheduler inserts all incoming I/O requests into a simple, unordered
FIFO queue and implements request merging.
The scheduler assumes I/O performance optimization will be handled at some
other layer of the I/O hierarchy; e.g., at the block device; by an intelligent HBA
such as a Serial Attached SCSI (SAS) RAID controller or by an externally
attached controller such as a storage subsystem accessed through a switched
Storage Area Network).
NOOP scheduler is best used with solid state devices such as flash memory
or in general with devices that do not depend on mechanical movement to
access data (meaning typical "hard disk" drive technology consisting of seek
time primarily, plus rotational latency). Such non-mechanical devices do not
require re-ordering of multiple I/O requests, a technique that groups together
I/O requests that are physically close together on the disk, thereby reducing
average seek time and the variability of I/O service time.
Noop isn't actually that bad. It's a simple I/O Scheduler and when it comes to Android, the simplest the better.
I think in G1 one known "tweak" was to set Noop as default I/O Scheduler.
pikachu01 said:
NOOP is a simple I/O scheduler without overhead that tries to do each I/O transaction as it comes (FIFO). When a group of transactions is detected, it will try to merge it together to make batches of transactions (makes the whole transaction faster). NOOP doesn't have starvation detection, hence if an I/O transaction takes a painfully long amount of time, it will still continue to do it rather than switch the CPU into doing something else e.g. GUI interrupts (i.e. scrolling lists, flicking screens). All other schedulers also have the "merge" feature. NOOP is the only one that makes the "merge" feature its only feature.
Click to expand...
Click to collapse
Anticipatory:
Code:
Anticipatory scheduling is an algorithm for scheduling hard disk input/output.
It seeks to increase the efficiency of disk utilization by "anticipating"
synchronous read operations.
"Deceptive idleness" is a situation where a process appears to be finished
reading from the disk when it is actually processing data in preparation of
the next read operation. This will cause a normal work-conserving I/O
scheduler to switch to servicing I/O from an unrelated process. This situation
is detrimental to the throughput of synchronous reads, as it degenerates into
a seeking workload. Anticipatory scheduling overcomes deceptive idleness
by pausing for a short time (a few milliseconds) after a read operation in
anticipation of another close-by read requests.
I have no idea if this fares well in Android devices. It's disabled in stock kernel and also in Quasar kernel since I've never heard of anyone using it or even recommending it. I read it's more in servers and what nots.
CFQ:
Code:
CFQ, also known as "Completely Fair Queuing", is an I/O scheduler for the
Linux kernel which was written in 2003 by Jens Axboe.
CFQ works by placing synchronous requests submitted by processes into
a number of per-process queues and then allocating timeslices for each of the
queues to access the disk. The length of the time slice and the number of
requests a queue is allowed to submit depends on the IO priority of the given
process. Asynchronous requests for all processes are batched together in fewer
queues, one per priority. While CFQ does not do explicit anticipatory IO
scheduling, it achieves the same effect of having good aggregate throughput for
the system as a whole, by allowing a process queue to idle at the end of
synchronous IO thereby "anticipating" further close IO from that process. It can
be considered a natural extension of granting IO time slices to a process.
Well, like Ondemand is to governors, CFQ is to I/O Schedulers. It's the most balanced one, aiming to perform well in most scenarios. However, in Android since things work differently, it's not the most suitable I/O Schedulers. There are many tweaks spreaded throughout XDA for improving this baby.
pikachu01 said:
CFQ is a complex I/O scheduler that tries to determine the address space of the transaction and applies a cost algorithm in that if the address is close together, it will group them up and perform them. It also tries to make the transaction incremental (i.e. reading/writing through address incrementally so that the disk spindle needs to wind down the least in conventional platter hard disks) The problem is, our flash devices have very little delta between reading a far reaching address space (than the one currently being written/read) or a closer one as it doesn't rely on spindle/rotations. Hence, having this costing algorithm adds overhead and slows down the overall transaction. CFQ has a lot of algorithms to make sure each process gets a fair slice of time on I/O transcations. Too much overhead.
Click to expand...
Click to collapse
Deadline:
Code:
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.
Deadline is actually quite popular along with BFQ. It is used in some known kernels for example Netarchy's for Nexus S. However, even though it's better than CFQ for Android devices it still falls short in comparison with VR.
pikachu01 said:
Deadline has a starvation detector and is simple enough that it doesn't have all the overhead of doing rotational/costing disks algorithm. However, reads are done 2x more likely than writes as it has a algorithm based on weights in that reads must be done first if both a read and a write is detected. It has a 2:1 ratio of read to write weights coded into the scheduler (that can be tweaked - writes_starved, will include it in the next version of system_tweak). Hence it's not a fair scheduler.
Click to expand...
Click to collapse
VR:
Code:
/*
* V(R) I/O Scheduler
*
* Copyright (C) 2007 Aaron Carroll <[email protected]>
*
*
* The algorithm:
*
* The next request is decided based on its distance from the last
* request, with a multiplicative penalty of `rev_penalty' applied
* for reversing the head direction. A rev_penalty of 1 means SSTF
* behaviour. As this variable is increased, the algorithm approaches
* pure SCAN. Setting rev_penalty to 0 forces SCAN.
*
* Async and synch requests are not treated seperately. Instead we
* rely on deadlines to ensure fairness.
*
*/
VR is a very good I/O Scheduler with Deadline elements. Probably the best for MTD Android devices and it's used also in known kernels such as IntersectRaven's for Nexus One. It's probably the one who can score the most in benchmarks but it's also one of the most... unstable. Its performance fluctuates, it can peak above average or it can go below it. But when it peaks... it's the best.
pikachu01 said:
V(R) tries to make sure that each transaction has a weight associated with it, being R. And if the seek is reversed, the R will be multiplied by a penalty making it less likely to be processed. Not for flash drives as reverse seek in a flash drive is just as fast as a forward seek.
Click to expand...
Click to collapse
Simple:
Code:
/*
* Simple IO scheduler
* Based on Noop, Deadline and V(R) IO schedulers.
*
* Copyright (C) 2010 Miguel Boton <[email protected]>
*
*
* This algorithm does not do any kind of sorting, as it is aimed for
* aleatory access devices, but it does some basic merging. We try to
* keep minimum overhead to achieve low latency.
*
* Asynchronous and synchronous requests are not treated separately, but
* we relay on deadlines to ensure fairness.
*
*/
Like the name suggests, Simple I/O is a simple one. Remember me saying that I/O Schedulers for Android devices, the simpler the better? This is such a case. Especially for EMMC devices. It's reliable and while not as good as VR when it peaks, it's still one of the best performance-wise. It's at the moment the default one in Quasar kernel.
pikachu01 said:
SIO is Simple I/O that tries to implement a NOOP type scheduler that has starvation detection. Hence, long I/O transactions will be preempted and given CPU time only after other faster transactions are completed, guaranteeing smoothness. Also, it doesn't have overhead of calculating costs. Also, it has a fair number of writes to read, guaranteeing that all transactions are equal.
Click to expand...
Click to collapse
BFQ:
Code:
/*
* BFQ, or Budget Fair Queueing, disk scheduler.
*
* Based on ideas and code from CFQ:
* Copyright (C) 2003 Jens Axboe <[email protected]>
*
* Copyright (C) 2008 Fabio Checconi <[email protected]>
* Paolo Valente <[email protected]>
*
* Licensed under the GPL-2 as detailed in the accompanying COPYING.BFQ file.
*
* BFQ is a proportional share disk scheduling algorithm based on the
* slice-by-slice service scheme of CFQ. But BFQ assigns budgets,
* measured in number of sectors, to tasks instead of time slices.
* The disk is not granted to the active task for a given time slice,
* but until it has exahusted its assigned budget. This change from
* the time to the service domain allows BFQ to distribute the disk
* bandwidth among tasks as desired, without any distortion due to
* ZBR, workload fluctuations or other factors. BFQ uses an ad hoc
* internal scheduler, called B-WF2Q+, to schedule tasks according to
* their budgets. Thanks to this accurate scheduler, BFQ can afford
* to assign high budgets to disk-bound non-seeky tasks (to boost the
* throughput), and yet guarantee low latencies to interactive and
* soft real-time applications.
*
*/
Here it is, the wrongly assumed best I/O Scheduler which happens to be the most popular one. It's based in CFQ but it has an inferior performance than VR or Simple, even if it's BFQv2 (although it seems to perform well in USB transfers rate).
pikachu01 said:
BFQ has a lot of algorithms to make sure each process gets a fair slice of bandwidth (Budget Fair Queueing). Too much overhead.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
pikachu01 said:
Here's my assessment of all the schedulers that I know:
SIO> NOOP> Deadline > VR > BFQ > CFQ
. . .
In benchmarking tests, the tests normally consists of testing the time it takes for a contiguous I/O transfer from 1 point to another. NOOP excels at that because it won't let itself get interrupted to perform another I/O task. This would mean that in real life testing, NOOP will let a long arduous task to finish while at the expense of UI functionality (you will get UI lags)
SIO on the other hand will perform badly at benchmarking as it gets pre-empted when the contiguous tasks takes more than 0.5secs (for synchronous tasks as benchmarking tools perform a synchronous I/O task from one point to another) to another more important task like UI interrupt (when you're scrolling) or Kernel interrupt (when your kernel needs to perform garbage collecting or swap memory etc)
The 0.5 secs can be tuned in the SIO tuneables though, but I would think 0.5 secs for synchronous tasks and 5 secs for async tasks is pretty good to maintain a balance between long/short tasks enabling a smoother experience in Android.
Click to expand...
Click to collapse
bbedward said:
Q: What is the zen I/O scheduler?
A: Well, the question that was asked above led me to an analysis of V(R ), deadline, and some others. I already knew, but realized "this is the main feature of V(R), but wait it has no benefit to us smartphone users." So I thought about adjusting the way V(R ) handled requests and how it dispatched them (I chose V(R ) because i'd rather not tinker with a scheduler thats official and widely supported). Then I was looking over it, and realized I might as well just write a new one I don't need any of this stuff. So I came up with something awfully similar to SIO, although its a bit simpler than SIO (closer to no-op) and works just slightly different.
- It's an FCFS (First come, first serve) based algorithm. It's not strictly FIFO. It does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, pretty much the same as no-op.
Click to expand...
Click to collapse
A little more info in the old toolbox
Excellent pooling of information. Well done; I have (or now had) several bookmarks to cover this information--and even those were somewhat spotty.
I would also suggest you take it a step further and list out some other apps that control these settings (FauxClock, System Tuner Pro, etc.) that manipulate this information and maybe list some setting to try out for i/o scheduling (cache size, etc.).
Anyway, great post.
I linked this over at the T-mobile Galaxay S II thread. . .
Great post. With my less significant amount of experience, I can agree on all opinions too.
Nice reference work, Simba. Thanks.
I cannot believe something like this went so unnoticed. Consider this added to the FAQ for future reference. Thanks for the great guide.
For those looking for more information about these and other kernel-based tweaks, there's droidphile's own posts (1 and 2) from the I9100 forums. I'm sure most of what's in the first one I linked is covered here though it also covers a bit more on other tweaks. Second post is for ICS kernels.
Divine_Madcat said:
I cannot believe something like this went so unnoticed. Consider this added to the FAQ for future reference. Thanks for the great guide.
Click to expand...
Click to collapse
+1 Holy cow!! How the hell did I miss this??
Thanks, Simba!
Edit: This should be STICKIED!!
Great information, thanks.
Sent from my SGH-I777 using xda premium
Can this be a sticky please
dirtbikerr450 said:
Can this be a sticky please
Click to expand...
Click to collapse
+1
Sent from my SGH-I777 using xda premium
Things don't get stickied in these forums now so there isn't a buildup of sticky threads like there used to be. Instead, one sticky which links to all the important guides and posts exists at the top. It makes the forums cleaner.
Sent from my SGH-I777 using XDA
karate104 said:
Things don't get stickied in these forums now so there isn't a buildup of sticky threads like there used to be. Instead, one sticky which links to all the important guides and posts exists at the top. It makes the forums cleaner.
Sent from my SGH-I777 using XDA
Click to expand...
Click to collapse
Only problem is that this thread is NOT linked in the existing sticky
eep2378 said:
Only problem is that this thread is NOT linked in the existing sticky
Click to expand...
Click to collapse
Agreed. And it should be.
karate104 said:
Agreed. And it should be.
Click to expand...
Click to collapse
PM sent to mod
eep2378 said:
PM sent to mod
Click to expand...
Click to collapse
Devine already did it like 7 posts up. Read! Lol
We will sort you out!
UltraBeast said:
Devine already did it like 7 posts up. Read! Lol
We will sort you out!
Click to expand...
Click to collapse
Woops! My bad. Its still kinda buried oh well
Red, disregard pm
eep2378 said:
Woops! My bad. Its still kinda buried oh well
Red, disregard pm
Click to expand...
Click to collapse
Its ok, I'm used to being overlooked.
As it is, it is linked in the FAQ - it is not on the "main" page, because it is a QA post, rather than guide, etc. This is excellent info though, which is why it is on the FAQ.
Divine_Madcat said:
Its ok, I'm used to being overlooked.
As it is, it is linked in the FAQ - it is not on the "main" page, because it is a QA post, rather than guide, etc. This is excellent info though, which is why it is on the FAQ.
Click to expand...
Click to collapse
I feel so bad sometimes because you are! I know you're around and active, but everyone just refers to Red when it comes to moderating XD
LuPuS JellyBean Kernel
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This kernel can be used on any JB CM BASED JB 4.1 or 4.2
Disclaimer
Code:
[COLOR="DarkOrchid"]#include[/COLOR] [COLOR="Magenta"][/COLOR]
[COLOR="Blue"]/*
* Your warranty is now void.. LOL I guess you knew it already.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, you getting dumped or you getting fired because your phone
* bootloops and alarm does not go off. Please do some research if you have any
* concerns about features included in my kernel before using it! YOU and only
* YOU are choosing to make these modifications.
*/
[COLOR="Magenta"]#ifdef[/COLOR]
You have a [COLOR="DarkGreen"]question[/COLOR] post it in the [COLOR="DarkRed"]thread[/COLOR],
Instead of [COLOR="DarkGreen"]Pm'ing me[/COLOR], as other users may
experience you [COLOR="DarkRed"]problems[/COLOR]
[COLOR="Magenta"]#endif[/COLOR][/COLOR]
What Works --
Wifi - (flash modules)
Bluetooth
Everything Else that works on FXP and any other JB kernel
What doesn't work --
Anything that doesn't work on FXP and any other JB kernel
Added Io-schedulers --
- Noop
- Anticipatory
- Deadline
- CFQ
- BFQ
- SIO
- ZEN
Added Governors --
- lagfree
- brazillianwax
- smoothass
- scary
- savagedzen
- smartass
- smartassv2
- smartassH3
- interactivex
- minmax
- + the 5or6 that are there with FXP
Lulzactive - Thanks to Tegrak
Based on Interactive and Smartass. When workload is greater than or equal to 60%, the governor scales up
CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step.
When screen is off, frequency is locked to global scaling minimum frequency
Virtuous
Virtuous is a modded smartassV2 which gives even more battery time then smartassV2
Intellidemand - Thanks to faux123
This is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling,
and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such.
Intellidemand does not jump to highest frequency when screen is off.
Lazy - Thanks to Ezekeel
The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand.
Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state
on a step overriding sampling interval.
Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always
select the maximum frequency while the screen is off.
-Ondemandx:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
-Lionheart:
Is a conservative-based governor. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
BadAss Governor:
Badass removes all of this "fast peaking" to the max frequency. 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 with 1024Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
Superbad -
A "superbad" super smooth rendition of a highly optimized "smartass" governor!
Darkside -
A "slightly more agressive smart" optimized governor!
Intellidemand2 - Thanks to faux123 and CosmicDan for mods
Uses d_bus ramping, quick and smooth and performance based, do not complain about battery drain on this
governor but it will make everything feel more like project butter
What else-----
-SLQB - (SLAB allocator with Queue)
This memory allocator is designed for small number of CPUs system (such as desktop or smart phone devices). This allocator is design to be simple and it is optimized for using order-0 pages as much as possible (order-0 pages are the simplest therefore quickest type of memory in a Linux system to allocate).
- Alot of changes to code to try improve smoothness ect
- Wifi signal lock on should now be quicker / stronger then before
--When LEDS change green, pink then blue press volume down to enter CWM Recovery
I would like to say a big thanks to -
slz.kiev - for amazing PACman ROM & Testing
FXP - Sources
Cyanogenmod - Souces
DooMLoRD - Everything he's done for XPeria
wechy77 - For helping me test
tempest918 - For the New Logo
xeozus
NobodyAtAll
Faux123
Erasmus
Leedroid
Phil3759
CTCaer
Anyone missing please PM me
Github Sources -b jellybean
https://github.com/garwedgess/semc-kernel-msm7x30
CWM source -- https://github.com/garwedgess/android_bootable_recovery -b lupus-cwm
LuPuS MENU
You can run lupus menu from terminal or scriptmanager or similar, you must run as root or script will exit with a message
in terminal
Code:
su
lupus
* information is in lupus menu
1/ CIFS Menu *
Enable
Disable
2/ zRam Menu *
Enable
Disable
Set zRam size ( default is 60)
3/ Frandom Menu *
Enable
Disable
4/ USB OTG *
Enable
Disable
5/ Clean and Remove tweaks
Remove init.d's
6/ Tweak Menu
Note all tweaks are preset from here and option to set as init.d's
Clean all temp files
SQLITE optimizations
LMK Optimizations
Network optimizations
Defend against ARP spoofing
Remove android logger
SDcard speed tweak
Flag blocks as non-rotational
7/ Performance Menu
Note all options are se by user input from here and option to set as init.d's
Set CPU frequencies
Set Governor
Set IO-Scheduler
Voltage Control
VM tweaks (explained below)
VM Tweaks
dirty ratio and dirty background ratio 1 & 2
This controls how often the kernel writes data to "disk" (in our case the internal microSD system card, not the removable microSD card). When your apps write data to disk, Linux actually doesn't write the data out to the disk right away, it actually writes the stuff to system memory and the kernel handles when and how the data is actually going to be flushed to the disk. These values represent a percentage, the higher the percentage, the longer it waits to flush, the lower the percentage, the more often flushes will occur. Now remember, we are dealing with solid state storage, not the traditional disk platter and spindle. So we are actually able to delay flushes a little longer with solid state versus a traditional hard drive disk.
dirty_expire_centisecs
How old "dirty" data should be before the kernel considers it old enough to be written to disk. It is expressed in 100ths of a second.
dirty_writeback_centisecs
This is the interval of when the writeback daemons periodically wake up and write "old" data out to disk. It is expressed in 100ths of a second.
min free kbytes
This is used to force the Linux VM to keep a minimum number of kilobytes free. The VM uses this number to compute a pages_min value for each lowmem zone in the system. Each lowmem zone gets a number of reserved free pages based proportionally on its size. Default is 2048kb.
overcommit_memory
This controls overcommit of system memory, possibly allowing processes to allocate (but not use) more memory than is actually available.
0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slighly more memory in this mode. This is the default.
1 - Always overcommit. Appropriate for some scientific applications.
2 - Don't overcommit. The total address space commit for the system is not permitted to exceed swap plus a configurable percentage (default is 50) of physical RAM. Depending on the percentage you use, in most situations this means a process will not be killed while attempting to use already-allocated memory but will receive errors on memory allocation as appropriate.
Swappiness
A property for the Linux kernel that changes the balance between swapping out runtime memory, as opposed to dropping pages from the system page cache. Swappiness can be set to values between 0 and 100 inclusive. A low value means the kernel will try to avoid swapping as much as possible where a higher value instead will make the kernel aggressively try to use swap space.
VFS Cache Pressure
File system cache (dentry/inode) is really more important than the block cache above in dirty ratio and dirty background ratio, so we really want the kernel to use up much more of the RAM for file system cache, this will increas the performance of the system without sacrificing performance at the application level. The default value is 100, as a percentage, and what you want to do is lower the value to tell the kernel to favor the file system cache and not drop them aggressively.
If you like my work please consider buying me a beer or something else
by clicking the DONATE ME button, of course it isn't needed but greatly appreciated and keeps me motivated.
Changelog ...............
Code:
[hide]
[B][v1] [/B]
- Initial release
- 25 Governors
- 6 Io-Schedulers
- SLQB memory allocator
- Built with linaro 4.6 toolchains
- Swap
- Zram enabled
- Custom voltage control supported
- Supports USB OTG
- Supports ext2, 3 & 4
[B][U]v2[/U][/B]
- Couple of extra tweaks - improvements to battery
- Fixed Wifi issues
- Reverted my disabling of disabling sched_feautures if you get that :P
- Added USB OTG modules needed for USB OTG ( find attached zip at the end of the post)
- Added stable freq-table for higher OCing upto 2ghz
[B][U]v3[/U][/B]
- Completely scrapped previous sources and started fresh
- CWM fixed thanks @ Scritch007
- Built with Linaro 4.7
- Optimized for Linaro
- Thumbee
- Reverted to 1.6 max OC
- Lzo patched
- Use Google Snappy Compression / Decompression
- Added TINY RCU
- Fixed Battery drain ( Tester lost 0.2% overnigh with wifi on ) :victory:
- Uses uncompressed Image {why .img size is bigger)
- Custom improvements for overall smoother performance
[B][U]v4[/U][/B]
- built with latest linaro 4.7.3 (02-01-2013) - Thanks @ ChainFirex
- Added memcopy
- Added compaction
- Lowered vfs_cache_pressure
- LMK (lowmemorykiller) optimizations
- Improved CIFS support
- Enabled USB tether
- Disabled gentle_fair_sleepers
- Updated video drivers
- Clean up on wifi config
- Back-ported binder changes
- TWRP recovery - thanks @ championswimmer & TWRP team
[B][U]v5[/U][/B]
- Built with Linaro 4.7.3 (02-01-2013)
- Free'd RAM (disabled 720p) now 381mb - Thanks at Paul678
- Makefile optimisations (snapdragon & neon) - Thanks at Paul678
- Tweaked permormance on interactive governor - Thanks at Paul678
- Tweaked SIO io sched - Thanks at Paul678
- Free'd some RAM from loggers
- Reduce swappiness
- Fix PageHead
- Fix binder. use of uninitialized variable.
- Fix kernel/net Memory Leaks
- Eliminate kstrdup memory leak
- ipv4: force_igmp_version ignored when a IGMPv3 query received
- Fix Entropy Depleting (no more depleting) - Thanks @ Kees Cook
- enable ipsec tunnel support in kernel (Latest FXP Change)
- ARM7 optimsations + more in config
- TWRP v2.4 - Thanks @ Championswimmer, TWRP Team
- Thanks [user=4402161]@Wechy77[/user] for LuPuS TWRP theme
[B]v6[/B]
- Supports both 4.1 & 4.2 JB
- New IIO Scheduler ZEN thanks [user=2632235]@bbedward[/user]
- New Governor smartassH3 thanks [user=3057569]@Hero[/user]
- Tweaked Deadline IO scheduler
- Tweaked smartassv2
- Frandom
- SFB Net scheduler
- OC up to 1804.8MHz
- Logger backported from CAF
- Free RAM from logger
- LMK updated and optimized + various LMK tweaks
- Various ARM & RAM changes
- TinyRCU optimizations
- Optimized crc32 lib
- various VM changes
- Improved cleancache
- Undervolt LCD display, touch sensor proximity sensor & Wi-Fi thanks @ M66B
- Entropy tweaks
- Try fix for CRT animation [user=4266283]@paul678[/user]
- TWRP & CWM
- LuPuS Menu
- Auto Loading wifi
- All modules and init.d's included No need to flash anything after kernel
Plus alot more changes see [URL="https://github.com/garwedgess/semc-kernel-msm7x30/commits/jellybean"] for full list of credits and patches used[/URL]
[B]v6[/B]
- Latest changes to ALS and Button Backlight -- Thanks @ FXP
- Lowered OC to 1612.8Mhz
- Remove ALS and Button Backlight option from LuPuS Menu (no longer needed)
- Random reboots should be fixed ( for those who where having such issues )
[B]v7[/B]
- Fixed 3D from hanging under high intensity
- Fix pmem for HDPI Mike NG] (no more reboots??)
- CWM Recovery = VOLUME DOWN
- TWRP Recovery = VOLUME UP
- Clean up on LuPuS Menu
- Better wifi check
- KEY RESET ( Menu and POWER)
- Tuned Smartassv3 and SmartassH3 [user=2799345]@M66B[/user]
[B]v8[/B]
- Fixed reboot to recovery on 4.2 (not sure if i broke it on 4.1)
---- Custom CWM
- Clean-up of menu
- Added own wipe options menu -- with extra options
- Aroma File Manager from CWM --- Must have aroma ([COLOR=Red]aromafm.zip) placed on root of sdcard[/COLOR])
- Multi zip installer
- Reboot options - Power off re-added under this menu
- Pointless but people keep asking me for it so re-added wipe battery stats also.
- LuPuS themed...
- Fixed "dancing android"
[/hide]
[B]v9[/B]
- Added option to enable Quick Key Reset (enable / disable via LuPuS Menu)
- Tuned Governors
* superbad
* lionheart
* virtuous
* darkside
* conservative
* smartassH3
- Really use google snappy zRam (improves zRam)
- Added zCache
- Removed persistent RAM
- Removed some more kernel debugging
- uninterruptible sleep
- Update SIO & CFQ
- Added Ultra-KSM
- Removed optimized AES & SHA1 routines
- Updated TWRP to 2.4.4
*Fixed Mount USB Storage in TWRP
- Updated CWM to latest Official CWM source
*Removed reboot options
*Re-added power off and reboot system now to main menu
- Improved wifi-loading scripts
- Clean up of lupus menu
- Fixed root issue on some devices
- Reworked kernel logs (can be found in /data/local/tmp)
- Boot.d - If phone is taking a long time to start move suspicious init.d scripts to /system/etc/boot.d
They will be run in background and won't affect boot time.
LuPuS-Jellybean-DOWNLOADS
If you like my work please consider buying me a beer or something else
by clicking the DONATE ME button, of course it isn't needed but greatly appreciated and keeps me motivated.
480p
LuPuS_urushi_jBv9-ram.img
md5 = 3ff24d7e343beb483aa81d7bcfa1b5f5
[/LIST]
720p
LuPuS_urushi_jBv9.1-full.img
md5 = 1effb6e2ba80afbb55d1bd9d30a426fd
[/LIST]
Mirrors -- all LuPuS Kernels can be found here
www.goo.im/devs/wedgess
Wifi is built in to kernels ramdisk NO MODULES NEEDED
If your MD5 doesn't match re-download
Everithing works fine so far. See benchmark scores.
Sent from my Xperia Ray using xda premium
Wow...nice one! Really responsive! Just wanted to point out that in addition to all the features listed in the OP, that you can undervolt
with this kernel....didn't see it as a feature in the OP...
Thanks!
justmpm said:
Wow...nice one! Really responsive! Just wanted to point out that in addition to all the features listed in the OP, that you can undervolt
with this kernel....didn't see it as a feature in the OP...
Thanks!
Click to expand...
Click to collapse
Lol ye i forgot to add it in to op thanks for reminding me.
Edit- Put of couple of more things into 3rd post, anymore I can remeber will be added
Sent from my GT-I9300 On Official JB
wedgess said:
Lol ye i forgot to add it in to op thanks for reminding me.
Edit- Put of couple of more things into 3rd post, anymore I can remeber will be added
Sent from my GT-I9300 On Official JB
Click to expand...
Click to collapse
very smooth, but has a problem the wifi seems works not stablely, sometimes cause reboot and sometimes cannot been disconnected.
feelow said:
very smooth, but has a problem the wifi seems works not stablely, sometimes cause reboot and sometimes cannot been disconnected.
Click to expand...
Click to collapse
Did you reboot? I have no problem with wifi. Only at first boot I had this problems.
Sent from my Xperia Ray using xda premium
testing...
(thx for your effort sofar :good
1st impression: lower scores on Antatu than with standard PAC-kernel.
i'd like to have a better battery life, so now testing "virtuous/sio, 806/134".
or are there better suggestions?
(like to keep a snappy Ray )
"Custom voltage control supported" not working. The PAC romcontrol says: not supported by your kernel
Wechy77 said:
"Custom voltage control supported" not working. The PAC romcontrol says: not supported by your kernel
Click to expand...
Click to collapse
I don't think that part of RC has been activated....it also doesn't work with the kernel from champilnswimmsr's aokp build. I am using incredicontrol from the play store...but a lot of other apps will let you change the volts.
justmpm said:
I don't think that part of RC has been activated....it also doesn't work with the kernel from champilnswimmsr's aokp build. I am using incredicontrol from the play store...but a lot of other apps will let you change the volts.
Click to expand...
Click to collapse
is there a list of recommended (or safe) voltage settings for the Ray?
Yes i know in rom control it still says not supported not sure why but u can always use SetXperia app from playstore to change it
And poster who asked about safe settings. Try down step -25mv at a time and see what is stable for you. If u get reboots then its obviously not stable.
Or else safest way if your wortied then dont undervolt at all. What maybe stable for someone might not be stable for you
Sent from my GT-I9300 On Official JB
I tryed thi kernel for my CM10 rom. And it seems buggy. Antutu points is lower than on stock kernel, and the perfomance is bad too, including games and UI.
_TREM_ said:
I tryed thi kernel for my CM10 rom. And it seems buggy. Antutu points is lower than on stock kernel, and the perfomance is bad too, including games and UI.
Click to expand...
Click to collapse
lol ok first off this is not stock kernel so you can't compare it to STOCK,Ssecondly i'm not sure what governors, io scheds and frequencies you are using. People who have tested have reported it being smooth and performance being greater not worse. Also I obviously use my own kernels on my own device and my experience is the complete opposite of yours. You sure it not 'your' CM10 rom. Buggy!! how? please do elaborate.
Anyone else confirm what the above pster has said ??
Using it now for some hours with Virtous and SIO and looks very promising. Speed of ROM is for me the same and I dont play games. But Battery seems to be great! I left the screen off a lot and have like 95% deep sleep, so pretty well battery ;D I use FXP142.
EDIT: just tested the game "granny smith'. Runs good! But I didnt test with another kernel.
[GER]Roxxor said:
Using it now for some hours with Virtous and SIO and looks very promising. Speed of ROM is for me the same and I dont play games. But Battery seems to be great! I left the screen off a lot and have like 95% deep sleep, so pretty well battery ;D I use FXP142.
EDIT: just tested the game "granny smith'. Runs good! But I didnt test with another kernel.
Click to expand...
Click to collapse
Ye virtuous is supposed to be more battery friendly then smartassv2
Intellidemand2 would be best performanced based but not the best on battery.
Sent from my GT-I9300 On Official JB
Thanks for the great kernel, really liking the Superbad governor.
I left my ray on during the night, to see what the battery would do...
(i mean screen off, but wifi+3g on)
from 100 to 74% in 9 hours.
8:40 deep sleep (94%)
806/134 virtuous/sio
I cannot compare btw, usually i charge at nighttime, but usage seems quite high?
was hoping for about 90% battery left or something, but like i said, not tested with other kernels.
I think I caught a "wifi" bug. Yesterday the wifi cut out and wouldn't turn back on...after rebooting everything was fine for a few hours and then wifi stopped working. I am not sure if it is really wifi or something else, because if I go into settings I see that wifi is on, I can turn it off but it won't turn back on...if I leave settings and pull down the status bar it show wifi as "on"...when I go back into settings it shows wifi as "on"...and no networks are shown that can be connected. You can do this over and over and every time you reenter settings it says wifi is on. I think it also causes a wakelock from wifestatemanager.
I went into recovery and formatted system and reinstalled PACman v15...a few hours later the problem returned. I flashed in a different kernel and it seemed OK....now I have your kernel on ChampionSwimmer's AOKP ROM and I am waiting to see if the bug returns.
I am not sure if there is something specific I do that activates the bug, so I don't have a logcat of it happening. I attached a logcat of me trying to turn on and off wifi in settings. I also attached the battery stats report from Better Battery Stats in case the wakelock is informative....
This is my version of crpalmer's kernel with some additional features:
-Android 5.0 support
-Sweep2Wake/Sweep2Sleep, DoubleTap2Wake (from Beastmode)
-force fast charge (credits to chad0989)
-kexec-hardboot support (for use with MultiROM, credits to Tasssadar for the multirom and the m7 patch I used)
-FauxSound (faux123)
-Moar overclockingz (up to 1890 mhz)
Note: Every chip is different, your device may not support these higher frequencies.
-GPU overclocking (up to 533 mhz) (credits to faux123, )
Note: Again, every chip is different, your device may not support higher frequencies.
-Additional CPU governors and I/O schedulers. Read about CPU governors here.
-Dynamic Fsync (faux123)
-Simple GPU Governor (faux123)
-L2 Cache overclock
-600 MHz bus overclock
-F2FS support (still no luck with getting this fully working, testers are welcome)
-LZ4 compressed kernel (faster boot)
-More TCP Congestion algorithms
-Lots of slimbus improvements thanks to poondog
For maximum performance, I recommend some optimized dalvik libraries (KitKat only):
-For 4.4.4 ROMs, use the "CM11 Dalvik_Final" zip in this post
-For older (4.4.2) ROMs:
-For 4.4.2 CM11-based ROMs released before March 1st, use my Sense dalvik libraries here.
-If you are using a 4.4.2 CM11-based ROM released after March 1st, or any ROM with this commit you will need to use the 4.4_qc-optimized_dalvik-cm11.zip here. Credits to kszaq for this one.
-For LiquidSmooth, use these Sense dalvik libraries here.
-Also, credits to kszaq because these were based on his flashable zip.
If you find any ROMs where none of these zips work, let me know and I will try to make one for that ROM.
I am not responsible for anything that happens to your phone. It is your device and your responsibility.
The following scripts are not required to change settings, they only exist as an alternative for people who don't want to use a third-party app. You can still use your favorite tuner app to tweak most of these kernel settings.
init.d tweaks
I created some scripts that run on boot (init.d) because I install my kernel so many times that I would go insane if I had to use an installer to configure it each time. By using these scripts and configuration files on the sdcard, I can just configure it once and keep installing away to my heart's content.
After installing this kernel, there will be:
/system/etc/init.d/99crpalmer
run at boot, even if you switch to another kernel. It is safe to leave this file there and to let it run as it only makes changes if the kernel contains "crpalmer" in the version. If run with a kernel that contains crpalmer in the version, it will rename mpdecision so it can't run. If you install another kernel it will then rename mpdecision back so that it will run in the new kernel. In addition to stopping the built-in mpdecision it will allow the following tweaks:
CPU Frequencies
* Frequencies loaded from /sdcard/crpalmer-cpufreq-min and /sdcard/crpalmer-cpufreq-max
* Governor loaded from /sdcard/crpalmer-cpufreq-governor
* If you specify either or both of these frequencies, it will lock down all of the CPU frequency controls. I had to do this because HTC overrides them in a script that is run very late in the boot process (thanks HTC!).
* E.g. adb shell su -c "echo 192000 > /sdcard/crpalmer-cpufreq-min"
* E.g. adb shell su -c "echo 1728000 > /sdcard/crpalmer-cpufreq-max"
* E.g. adb shell su -c "echo interactive > /sdcard/crpalmer-cpufreq-governor"
Undervolting
* + or - value loaded from /sdcard/crplamer-uv
* The undervolting in 2.0.23 for FAST binned CPUs would be specified as:
* E.g. adb shell su -c "echo -100 > /sdcard/crpalmer-uv"
Lightsensor
* My light sensor changes didn't sound like they worked well for everyone. If you don't like them you can disable them by:
* E.g. adb shell touch /sdcard/crpalmer-stock-lightsensor
HTC Colour "Enhancement"
* If this file is present then the HTC's colour "enhancement" will be used, otherwise it will be disabled.
* If this file contains the string "m7" then it will use one of the colour enhancement that was used in the M7 kernel for a panel most like ours.
* E.g. adb shell touch /sdcard/crpalmer-color-enhancement
Click to expand...
Click to collapse
DoubleTap2Wake:
* This allows you to wake the device by double tapping in the bottom half of the screen, just above the hardware keys.
* To enable or disable, create the file /sdcard/jamiethemorris-dt2w
* If this file contains a 1, dt2w is enabled. If it contains a 0 it is disabled. Enabled by default.
Sweep2Wake/Sweep2Sleep:
* This allows you to wake the device by sweeping from left to right over the hardware keys, and sleep the device by sweeping from right to left.
* To enable or disable this, create the file /sdcard/jamiethemorris-s2w.
* If the file contains a 1, s2w and s2s are enabled. If it contains a 0, they are disabled. Enabled by default.
GPU Overclock:
* The GPU's max frequency is loaded from /sdcard/jamiethemorris-gpu-oc. If this file does not exist, the stock frequency of 400 MHz is used.
* To set this GPU overclock, you need that file containing the GPU frequency in MHz. Frequencies from 400 to 550 MHz are available.
* E.g. adb shell su -c "echo 450 > /sdcard/jamiethemorris-gpu-oc"
GPU Governor:
* You can choose from either ondemand, simple, or performance GPU governors. Default is ondemand.
* The governor is loaded from /sdcard/jamiethemorris-gpu-gov
* E.g. adb shell su -c "echo simple > /sdcard/jamiethemorris-gpu-gov"
Dynamic Fsync:
* From Faux123: The dynamic sync control interface uses Android kernel's unique early suspend / lat resume interface. While screen is on, file sync is disabled. When screen is off, a file sync is called to flush all outstanding writes and restore file sync operation as normal.
* Disabled by default. To enable or disable, create the file /sdcard/jamiethemorris-dyn-fsync. Use 0 to disable and 1 to enable.
Force Fast Charge:
* To enable or disable fast charge, create the file /sdcard/jamiethemorris-fastcharge
* Use 0 to disable, and 1 to enable. Disabled by default.
Intelliplug and Eco Mode:
* Intelliplug is a replacement hotplug driver for HTC's mpdecision, Eco Mode limits your device to dual-core operations.
* To enable or disable, use create the file /sdcard/jamiethemorris-intelliplug
* If the file contains 0, intelliplug and eco mode are both disabled and your phone will use crpalmer's hotplug driver. If the file contains a 1, intelliplug is enabled but eco mode is disabled. If the file contains the string 'eco', intelliplug and eco mode are both enabled. Both are disabled by default.
I/O Scheduler:
* To change the I/O scheduler, create the file /sdcard/jamiethemorris-iosched, and your device will use whatever I/O scheduler you specify.
* E.g. adb shell su -c "echo row > /sdcard/jamiethemorris-iosched"
Undervolt Override:
* This allows you to globally undervolt your device, but leave the 1836 MHz, 1890 MHz, and 1917 MHz frequencies at their default voltages.
* To enable or disable:
- First you need to find your PVS bin number. You can find this by checking the file /sys/module/acpuclock_krait/parameters/pvs_number.
- Create the file /sdcard/jamiethemorris-pvs and put your PVS number in that file.
- After a reboot, your device will automatically set the highest frequencies to the default voltages for your chip.
* If you are either lazy or confused, you can put '?' in the file and your phone will set itself to the voltages for a 'nominal' binned chip.
For the rest of the features and changelog, see crpalmer's original cm11 kernel thread.
Thanks: crpalmer for all of his help (before I started on this I didn't even know how to use git), coachcrey for originally inspiring me to do this, and all the other devs/builders here that may or may not know I'm learning from them constantly.
Downloads
Latest version:
Version 6.0.1
Older versions:
Older versions on Android File Host
Source:
Kernel Source
Build Tools
Recommended Settings
You can either use an app such as TricksterMod or Kernel Tweaker to set these parameters or use my scripts.
-Minimum CPU frequency: 162000
-Maximum CPU frequency: 1890000 for performance, 1512 for battery life, 1728 for balanced
-Undervolt: -100 for battery life, -50 for balanced/stability
-Color enhancement (script only): m7
-DoubleTap2Wake: Enabled for convenience or pretending you have a G2, disabled for battery life
-Sweep2Wake: Enabled for convenience, disabled for battery life
-Fastcharge: Disabled for safety, enabled for convenience
-GPU overclock: 500 MHz or 533 MHz for performance, 400 MHz or 320 MHz for battery life, 450 MHz for balanced
-GPU governor: ondemand for battery, simple for performance
-CPU governor: preservative for battery or balanced (decrease up threshold for faster response at the expense of battery), intelliactive for general performance, performance for benchmarking
-Intelliplug/Eco mode: Disabled for performance, enabled for balanced, Eco Mode for battery life
-I/O Scheduler: BFQ for balanced/stability, vr for performance
-Dynamic Fsync: Disabled for safety (less likely to have data loss in the event of sudden power off), enabled for performance, enabled for balanced
-Undervolt Override (script only): set jamiethemorris-pvs to your chip's PVS bin. Recommended for those with high overclock that are undervolted.
To make things easier for those who do not wish to use a third-party app, I have posted some zips with the necessary files. Just unzip them and put the files on your sdcard.
Default settings
Recommended settings (these are the settings I use, good performance vs. battery compromise
For best battery life
For best performance
XDA:DevDB Information
jamiethemorris's kernel, Kernel for the HTC Droid DNA
Contributors
jamiethemorris, crpalmer
Source Code: https://github.com/jamiethemorris/dna-kernel/tree/6.x
Kernel Special Features: dt2w, kexec-hardboot, overclock, fastcharge, fauxsound
Version Information
Status: Stable
Created 2014-01-28
Last Updated 2014-12-04
Changelog:
6.0.1
- All updates from CM:
- F2FS updates. Maybe F2FS works now (probably not).
- UID-based routing
- Enable selinux development
- Initial support for Lollipop (KitKat 4.4.4 ROMs are still supported)
5.8.2
- Updates from crpalmer:
* Update some video bandwidth parameters
* Interactive governor updates
- Pretty sure that's it.
5.8.1
- Updates from crpalmer:
* Patched up to linux 3.4.99 (latest version of as now)
* Patched up to latest CM (fixes a couple of CVEs, not a whole lot else was missing)
5.7.7.1:
-Force Fast Charge should now be fixed
-Make sure all cores are enabled when using performance CPU governor
5.7.7:
-Moved from Linaro 4.8.3 to 4.9.1
-Update modem restart commit from stock CM kernel
-No more intelliplug due to random reboots and the fact that simple plug works just fine. I may bring it back future versions.
-Reduce memory usage of input driver + oom tweaks that theoretically help a little bit with the touchscreen wake issue. I am still working on finding a real fix.
-SLIMBUS: m8 port, caf updates, new OC from poondog (better audio quality)
-Update BFQ to v7r3
-Update to latest F2FS driver
Older versions:
5.7.6:
-NOTE: There are 2 different zips for this version to avoid conflicts between crpalmer's simple plug and faux123's intelliplug.
-IMPORTANT: On the intelliplug version, intelliplug is enabled by default. If you disable intelliplug, there will be no hotplug driver running which will kill your battery quickly. So if you decide you don't want to use intellidemand, please use the simple plug version instead.
-Memory optimizations from Motorola
-Enable Linaro's power-efficient workqueues
-Intelliplug updates
-Merge latest CM commits
-Merge crpalmer's latest commits
-Update to Linux 3.4.86
-Update F2FS to the latest version
5.6.4:
-Hopefully fix voltage for "faster" binned chips
-Fixed random reboots when using intellidemand governor
-Fix scripts
-Disable intellidemand's active max frequency to prevent it from interfering with overclock
-Enable additional TCP congestion algorithms (thanks iHateWebOS)
-Sync s2w/dt2w/pocket detection with Beastmode
-Add Preservative governor (credits to bedalus)
-Update BFQ I/O Scheduler to v7r2
-Merge latest CM commits
-Merge crpalmer's latest commits
-Update to Linux 3.4.79
-Add LZ4 kernel compression/decompression for faster boot
-I think I forgot to mention this before, but I am now using a Cortex a-15 optimized Linaro toolchain.
5.5.5:
-Dynamic Fsync (Enable this only if you are sure your device is stable! If you have too many reboots, your data may get corrupted and you will have to reflash your ROM.)
-Simple GPU Governor
-Intelliplug hotplug driver with Eco mode (dual core operations). When this is disabled, it will use crpalmer's hot-plug driver.
-Intellidemand tweaks - I'm still working on this one, it tends to have random reboots at the moment.
-Decrease GPU OC to 533 MHz and increase bandwidth
-1917 MHz overclock is back, should be more stable now
-Sweep2wake + Sweep2Sleep
-Doubletap2sleep is not implemented in this version, sorry. Use your ROM's dt2s feature for now. I do plan on adding this back.
-Doubletap2wake can be used anywhere on the screen
-There should be scripts for all features, let me know if I missed something.
-Undervolt override for high overclocks. You can globally undervolt while leaving 1836 MHz, 1890 MHz, and 1917 MHz clocks unaffected.
-L2 cache overclock
-600 MHz bus overclock for 1674 MHz - 1917 MHz frequencies
-Support for F2FS filesystem (F2FS TWRP and MultiROM are coming as well, as soon as I have time to test)
-FIOPS I/O Scheduler
5.5.4.1:
-Now only one kernel zip
-GPU overclock is set with /sdcard/jamiethemorris-gpu-oc between 400 and 550 MHz. Default is 400.
-New wheatley governor
-Some more optimizations
5.5.4:
-Fixed video undderrun (blue flickering) issue with GPU overclock
-Updated FauxSound to 2.1
-Now only 2 kernel zips. One is stock GPU clock and the other is for 450 and 500 mhz overclocks. Default is 500 on the OC version.
-New governors: intellidemand, intelliactive, smartassV2, lagfree, badass, Lionheart
-New I/O Schedulers: zen, vr
-Improved touchscreen sensitivity - If this causes problems for people I will revert it.
-SLIMbus overclock which should in theory improve audio quality
-Various performance optimizations, see github for full details
5.5.3.4:
-Switch linaro optimization level from -03 to -0fast
-A few other optimizations, see github for full details
5.5.3.3: Up to 500 mhz GPU overclock. For now, there are 3 different downloads depending on what GPU frequency you want - stock (400 mhz), 450 mhz, and 500 mhz. There are no other changes, so if you don't want a GPU overclock there is no need to update to this version.
5.5.3.2: Up to 1890 mhz CPU overclock
5.5.3.1: Added FauxSound
Nice work man!
Sent from my HTC6500LVW using Tapatalk
Multirom link is in the op. I plan on getting s2w working soon also. The code is there, but it's made for an HTC one so it doesn't work yet. Technically logo2menu is in there as well lol
Sent from my Droid DNA using Tapatalk
Dt2w works perfect! Will this kernel be updates as CP pushes changes in the future?
HTC DNA
LG Optimus G
d08speed3 said:
Dt2w works perfect! Will this kernel be updates as CP pushes changes in the future?
HTC DNA
LG Optimus G
Click to expand...
Click to collapse
Yes, that is the plan
Sent from my Droid DNA using Tapatalk
CM double tap to sleep. Doesn't work well with dt2s. It turns off then back on.
HTC DNA
LG Optimus G
---------- Post added at 07:57 AM ---------- Previous post was at 07:56 AM ----------
d08speed3 said:
CM double tap to sleep. Doesn't work well with dt2s. It turns off then back on.
HTC DNA
LG Optimus G
Click to expand...
Click to collapse
Edit: turning the CM dt2s works. I'm guessing you have this enabled for status bar double tap to sleep?
HTC DNA
LG Optimus G
d08speed3 said:
CM double tap to sleep. Doesn't work well with dt2s. It turns off then back on.
HTC DNA
LG Optimus G
---------- Post added at 07:57 AM ---------- Previous post was at 07:56 AM ----------
Edit: turning the CM dt2s works. I'm guessing you have this enabled for status bar double tap to sleep?
HTC DNA
LG Optimus G
Click to expand...
Click to collapse
Just to clarify, in that last edit you're just saying that turning dt2s off in the settings makes the kernel's version of dt2s work right? Cause that's what I'm seeing on my phone. Thanks for the heads up, I enabled the dt2s setting a while ago but I always forget that I did so I hadn't tested it yet.
Sent from my Droid DNA using Tapatalk
jamiethemorris said:
Just to clarify, in that last edit you're just saying that turning dt2s off in the settings makes the kernel's version of dt2s work right? Cause that's what I'm seeing on my phone. Thanks for the heads up, I enabled the dt2s setting a while ago but I always forget that I did so I hadn't tested it yet.
Sent from my Droid DNA using Tapatalk
Click to expand...
Click to collapse
Yea. Turning off CM's dt2s settings off makes your dt2s work. I see it enabled in sys>android_touch.
HTC DNA
LG Optimus G
d08speed3 said:
Yea. Turning off CM's dt2s settings off makes your dt2s work. I see it enabled in sys>android_touch.
HTC DNA
LG Optimus G
Click to expand...
Click to collapse
Got it. Looks like this was bad timing to release a kernel, apparently we're moving from m7 to msm8960 soon...
Sent from my Droid DNA using Tapatalk
i love the convenience of s2w and dt2w and now we have it for aosp and sense! what a awesome time this is to own a dna
Swipe or double tap to sleep isn't working. Normal?
-DroidIsDNA- said:
Swipe or double tap to sleep isn't working. Normal?
Click to expand...
Click to collapse
Dt2s is working for me. S2w isn't functional yet. Is dt2w working for you?
If you have dt2s enabled in your ROM settings, make sure you disable it as out counteracts the kernel's dt2s.
Sent from my Droid DNA using Tapatalk
jamiethemorris said:
Dt2s is working for me. S2w isn't functional yet. Is dt2w working for you?
If you have dt2s enabled in your ROM settings, make sure you disable it as out counteracts the kernel's dt2s.
Sent from my Droid DNA using Tapatalk
Click to expand...
Click to collapse
I don't think I have it enabled in probam. Dt2w doesn't work
-DroidIsDNA- said:
I don't think I have it enabled in probam. Dt2w doesn't work
Click to expand...
Click to collapse
Did you follow the instructions in the op to enable it? It should be enabled by default I think but if not I put instructions there
Sent from my Droid DNA using Tapatalk
jamiethemorris said:
Did you follow the instructions in the op to enable it? It should be enabled by default I think but if not I put instructions there
Sent from my Droid DNA using Tapatalk
Click to expand...
Click to collapse
Oops I meant double tap to sleep I'm sorry
-DroidIsDNA- said:
Oops I meant double tap to sleep I'm sorry
Click to expand...
Click to collapse
That's weird then. You have to double tap the status bar in case you didn't already know that. If that's still not working, then enabling the ROMs version of it in settings should do the trick.
Sent from my Droid DNA using Tapatalk
jamiethemorris said:
That's weird then. You have to double tap the status bar in case you didn't already know that. If that's still not working, then enabling the ROMs version of it in settings should do the trick.
Sent from my Droid DNA using Tapatalk
Click to expand...
Click to collapse
Ohhhhhh, yeah I was double tapping above the menu keys. Status bar works flawlessly. Thanks! Idk if its in the op or if I just blanked out
-DroidIsDNA- said:
Ohhhhhh, yeah I was double tapping above the menu keys. Status bar works flawlessly. Thanks! Idk if its in the op or if I just blanked out
Click to expand...
Click to collapse
It actually wasn't in the OP, I just added it for clarification.
Is force fast charge on by default?
HTC DNA
LG Optimus G
Hi all,
I hate long ops. I decided to switch back to CM13 and also you wont miss my kernel there here you go.
A small fast and stable kernel without any bull**** inside
Downloads
http://forum.xda-developers.com/devdb/project/?id=13188#downloads
Source Code:
https://github.com/DerRomtester/one_plus_one/tree/cm13
XDA:DevDB Information
Tyr CM13 Kernel, Kernel for the OnePlus One
Contributors
DerRomtester
Kernel Special Features:
Version Information
Status: Stable
Created 2015-12-27
Last Updated 2015-12-27
Changelog:
V3
* francos thermal driver
* improvement better charging speed
*mako hotplug
*tuned row scheduler for better performance
*tuned bfq scheduler for better performance
*tuned cfq scheduler for better performance
*tuned deadline scheduler for better performance
*tuned cache pressure for better performance
*disabled crc for better performance
*francos sound control driver
*34% improvement in the I/O latency
*added controls for sched features
*Added fsync on/off support.
*disabled gentle_fair_sleepers and arch_power by default to reduce battery drain *and improve stability
*some compiler optimizations for cortex a15
*fixed a possible memory leak
ecc.
Will test it soon
My first cycle from around 90% to 3% battery. Surfing, watching videos playing small games and Google + Facebook Instagramm etc.
Which UKM do you recommend?.. Is your version still completely compatible?
Setting.Out said:
Which UKM do you recommend?.. Is your version still completely compatible?
Click to expand...
Click to collapse
I am happy with kernel adiutor. And also i recommend to use that app
Synapse + UKM is sometimes a bit buggy so i dont want to spent to much time for UKM.
Version 4
I suggest using the latest CM nightly for this build!
* improvement: cm upstream updates up to that patch video: mdss: Improve the LiveDisplay driver
* improvement: O3 compiler optimization and some different compiler optimizations for our cpu to increase the performance
* kernel size slightly increased because of that optimizations but i don't care about that
* improvement: compiled with UBER Toolchain 5.3 for better performance ( i hope it is as battery friendly as the 4.9 toolchain)
I think thats it
Dont forget to hit Thx.
DerRomtester said:
Version 4
I suggest using the latest CM nightly for this build!
* improvement: cm upstream updates up to that patch video: mdss: Improve the LiveDisplay driver
* improvement: O3 compiler optimization and some different compiler optimizations for our cpu to increase the performance
* kernel size slightly increased because of that optimizations but i don't care about that
* improvement: compiled with UBER Toolchain 5.3 for better performance ( i hope it is as battery friendly as the 4.9 toolchain)
I think thats it
Dont forget to hit Thx.
Click to expand...
Click to collapse
The throttle is rather aggressive.. 60° is a pretty low throttle point and to go instantly down to 1.47 GHz.. Could it throttle in steps maybe or the starting temp get raised?..
Setting.Out said:
The throttle is rather aggressive.. 60° is a pretty low throttle point and to go instantly down to 1.47 GHz.. Could it throttle in steps maybe or the starting temp get raised?..
Click to expand...
Click to collapse
I think it is ok to throttle at 70°C but you still can raise it if you want. I try to modify the driver a bit in the future. I just picked it from franco without any further tuning.
DerRomtester said:
I think it is ok to throttle at 70°C but you still can raise it if you want. I try to modify the driver a bit in the future. I just picked it from franco without any further tuning.
Click to expand...
Click to collapse
I'll try the auditor.. Synapse was pegged at 60°..
Setting.Out said:
I'll try the auditor.. Synapse was pegged at 60°..
Click to expand...
Click to collapse
Yeah as i said before it is sometimes a bit buggy. Just uninstall it
Version 5
* updated thermal driver to read the CPU temperature from the vadc sensor
The adc channel is more accurate than tsens and so we have accurate throttling this means the device starts to throttle when it feels actually hot
current CPU temperature (vdac the new sensor) can be found inside that file:
/sys/devices/qpnp-vadc-ee156800/xo_therm_pu2
I dont know a terminal command yet to do this
* compiler optimizations
* fixed a bug that introduced cm which is causing space memory corruption
* added voltage control
* improvement: better idle drain during processor retention c-state
* added Qualcom CPU reference table (cpu frequencies suggest by Qualcom for this processor)
* added 268mhz GPU step (should help for better idle drain)
* fixed simple ondemand gpu governor crashing on startup
* improvement: better mmc performance
* improvement: enabled idle power collapse for better idle drain
* fixed: report correct GPU frequency
* improvement: reduced overhead under high-freq idling patterns
* improvement: drop nfc freq to 19.2 MHz for better battery drain
* fixed: some compiler warnings
* fixed: low brightness flickering
* forced min CPU frequency to 268mhz and max CPU frequency to 2457mhz this fixes cores stuck at max frequency after a reboot
Dont forget to hit thx
DerRomtester said:
Version 5
* updated thermal driver to read the CPU temperature from the vadc sensor
The adc channel is more accurate than tsens and so we have accurate throttling this means the device starts to throttle when it feels actually hot
current CPU temperature (vdac the new sensor) can be found inside that file:
/sys/devices/qpnp-vadc-ee156800/xo_therm_pu2
I dont know a terminal command yet to do this
* compiler optimizations
* fixed a bug that introduced cm which is causing space memory corruption
* added voltage control
* improvement: better idle drain during processor retention c-state
* added Qualcom CPU reference table (cpu frequencies suggest by Qualcom for this processor)
* added 268mhz GPU step (should help for better idle drain)
* fixed simple ondemand gpu governor crashing on startup
* improvement: better mmc performance
* improvement: enabled idle power collapse for better idle drain
* fixed: report correct GPU frequency
* improvement: reduced overhead under high-freq idling patterns
* improvement: drop nfc freq to 19.2 MHz for better battery drain
* fixed: some compiler warnings
* fixed: low brightness flickering
* forced min CPU frequency to 268mhz and max CPU frequency to 2457mhz this fixes cores stuck at max frequency after a reboot
Dont forget to hit thx
Click to expand...
Click to collapse
Kcal?
usmani said:
Kcal?
Click to expand...
Click to collapse
Not yet But you can use life display settings until i have implemented that feature.
Sorry for the OT but since you have switched to CM13 as of now, are you also working on the CAF kernel? Can we expect an update to that kernel as the last version released was on 12/13. I have just recently swithced to CM13 CAF so would like to stay and test for a while before switching back to CM13.
Wow great! Glade to see your Kernel for cm 13!
Will Flash it right now.
Greetings from Hamburg
Gesendet von meinem SGP511 mit Tapatalk
abhibnl said:
Sorry for the OT but since you have switched to CM13 as of now, are you also working on the CAF kernel? Can we expect an update to that kernel as the last version released was on 12/13. I have just recently swithced to CM13 CAF so would like to stay and test for a while before switching back to CM13.
Click to expand...
Click to collapse
Yes i am gonna update CAF kernel soon with upstream changes from sultanxda.
DerRomtester said:
Yes i am gonna update CAF kernel soon with upstream changes from sultanxda.
Click to expand...
Click to collapse
I'm facing visual artifacts with v5 and 29 nightly.
usmani said:
I'm facing visual artifacts with v5 and 29 nightly.
Click to expand...
Click to collapse
Nothing in kernel sie has been changed that would cause sth like that. You changed DPI? Rom related issue.
Do you use the stock Mako Hotplugg Settings or do you changed it to "Zen mode" with all 4 cores online?
I will test it with stock Mako Settings and will then go on to the allways quad core mode.
And which I/O Scheduler do you recommend? I´m not sure fiops vs row are my favourites.