Develop Bugs

[Kernel] Flykernel-13 "Back from the Grave"

FlyKernel is an overclockable kernel for the Hero GSM, aimed to improve stability, battery life and performance (generally in that order).
The Hero GSM now also has a newer .35 kernel "Las Venturas" you should also check that one out. At the time of writing these lines, the newest version of Las Venturax is found on the second post of the above thread (my post ) - you should check which post is more up-to-date on that thread.
Download and instructions are on this post.
FAQ and advanced subjects are on the second post.
Change log and previous versions are on the third post.
WARNING: Please make sure to have an up-to-date backup before you flash this kernel!
FlyKernel-13 (#253)
FlyKernel 13 - Desean
FlyKernel 13 - Mediafire
FlyKernel 13 - Multiupload
This is a post-LasVenturas update for FlyKernel, after quite some time without any updates.
Although I currently have a bit of a personal preference for Las Venturas, I believe that it is even better to have two excellent kernels for the hero (internally totally different ), so that the users can choose whichever works best for them. Possibly, on some of the older ROMs this kernel might work better. This should also help isolate kernel issues vs. ROM issues.
SmartassV2 (informal description and comparison with the first smartass)
SmartassV2 is a governor (controls the frequency of the CPU at each give moment) which like the first smartass is generally based on the implementation of interactive with some major changes and the addition of a built in sleep profile (behaves a bit differently when screen is off vs. on).
The smartassV2 improves the very naive scheme which the first smartass had: The first smartass (with the values I set for the hero), would cap the max frequency at 352Mhz for sleep and when screen is on, would do the opposite and keep the frequency at 518Mhz or above. For sleep this was very effective but a bit crude and unclean, and there could be some cases where you would need processing power even when screen is off (something is updating and music is playing and etc.). For screen on, smartass1 was too quick to jump to the max available frequency and again would never go below the 518Mhz, so in a nutshell its was using "too high" frequencies.
SmartassV2, introduce (internally) an "ideal" frequency which is the frequency we are "aiming" for, in some sense. The way I see it is that the "ideal" frequency is a hint to the governor what is a good balance between performance and battery life. Now when screen is on, I set (on the hero) the ideal frequency to 518Mhz which will ensure nice responsiveness but limit unnecessary use of higher frequencies when they are not needed. When screen is off, I set the ideal frequency to 352Mhz (0 will disable the screen state tracking all together). From my testing this will "convince" the governor to spend most of the its time during sleep at the lowest available frequencies. Note, that both during sleep and when awake the entire frequency range (as defined by the "user" - i.e. selected with SetCPU) is used by smartassV2. For example, when the CPU is loaded heavily, the highest available frequency will be used regardless if screen is on or off.
Boot OC and optional tweaks
Optionally, you can rename the update file before you flash to change bootup frequencies and other options.
If you don't rename the file and flash "FlyKernel-13.zip" you will get the default tweaks and the min/max frequencies will remain as they where before.
For example, to set the max/min frequencies on boot to 614/176, rename "FlyKernel-13.zip" to "FlyKernel-13-M614-m176.zip".
Supported "flags" are:
Notice, all flags are case sensitive.
-MXXX - set max frequency to XXX
-mYYY - set min frequency to YYY
Supported max frequencies:
518 576 614 633 652 672 691 710 729 748
Supported min frequencies:
19 176 264 352 518 576 614 633 652 672 691 710 729 748
Default behavior, if these flags aren't given, is not to change your current settings.
For frequency recommendations and more info see FAQ #5.
Technical details: max/min frequencies are set in the kernel's ramdisk init.hero.rc file. Previous settings will be replaced. Furthermore, if one of your init.d script sets the max/min frequencies, these lines will be removed.
If you have SetCPU or other program changing the speed at boot, their change will take effect and overwrite this setting as soon as the ROM completes to boot.
-nologo - Don't show boot animation.
-logo - Show boot animation.
Default behaviour, if no flag is given, is not to change your current settings.
-noatime - Mount all partitions with -noatime to improve IO.
-atime - Mount no partition with -noatime.
Assuming, your ROM did not mount any partition with noatime, then the -atime option should undo the -noatime option perfectly. Unfortunately, it seems some ROMs (i.e. VR12) mount only some of the partitions with -noatime. It seems that in some cases, changing the noatime configuration causes boot problems.
Therefore, I highly recommend you make a backup before trying the -noatime flag - this is the only full proof way to go back if it messes something up.
Notice, this does not effect the ext partition as it is not mounted in the ramdisk init.rc. As far as I know, all ROMs mount the ext partition with noatime.
-notweak
By default, the updater will remove scheduler tweaks which exists in the ramdisk init.rc script, in order for the scheduler default compiled into the kernel to apply. This flag will disable this behavior.
More techinical information for developers about the smart update package has been updated in my github wiki.
Limitations and known bugs:
- This kernel will not make you coffee (I hope)!
Integrating kernel in a custom ROM (for ROM developers)
You can use my from above:
http://floyo.desean.net/FlyKernel-13-Floyo.zip
This file has a regular boot.img with a ramdisk compatible with Floyo 1.4, boots at 576/352 (smartassV2) and has all the kernel modules unpacked.
If you need to edit the ramdisk, you can either unpack the above boot.img as explained here. Or you can get the kernel binary file from my smart update package, under tmp/flykernel/kernel. The kernel modules are package in the smart update package under tmp/flykernel/syslibs.tar.
Kernel Sources
My sources with all my updates and changes are found on github:
http://github.com/erasmux/hero-2.6.29-flykernel
Use hero_defconfig for the regular version and hero-bfs_defconfig for the BFS version.
See the wiki for more information about building the kernel and more.
Please feel free to contact me regarding my sources and kernel development.
Using my Kernel Sources
Feel free to use my kernel sources, fully or partially in any (legal) way you see fit.
If you modify the sources, I urge you to share your changes with the community (as GPL obliges you to do), preferably using github. You can fork my sources on github, and this will make it easier for you to grab new changes from me and also allow you to fill pull requests so I can pull your changes back to my kernel.
GPL
Yes I am GPL complaint, all is included inside the sources, including the GPL license itself.
Thanks
Huge thanks to Desean for giving me file hosting that makes my life easier
Many thanks to all the Kernel/ROM developers here, especially those with open source kernels on github - LoxK, Cyanogen, Ninpo, Radu and especially Decad3nce.
Big thanks to all those who helped test the pre versions and reported bugs, specifically also to my long time testers (moonshield and floomat)
Donations are always welcome and accepted but are in no way required.

FAQ and Advanced Subjects
FAQ
0. When reporting a problem, do I need to include the ROM and exact kernel version I am using?
YES!
1. How do I flash the kernel update file?
You flash it from recovery, like any other custom ROM. If you are not familiar with recovery and/or haven't rooted your phone, start here.
2. Do I need to wipe anything when installing the kernel?
No you don't need to do any wipes. Just install the kernel through recovery and reboot
3. The update from recovery failed with errors/warning?
Please, in the same recovery session which you tried to apply the update and failed, select the "Move recovery.log to SD" from the "Other" menu and post in this thread with the recovery.log attached (for example in a .zip file).
4. After flashing the kernel my ROM does not boot
A logcat of the boot process might help me understand the problem. Using adb you can generate one with the following command and attach it to your report:
Code:
adb logcat > logcat.txt
You need to run this command relatively close to the start of the boot. Close the window after the phone is stuck for few minutes (say 2 mins with no change should do). You can start by running "adb logcat" and seeing if you get any output at all. If so, reboot once more and run the above command from the start of the boot (approximately).
Please also clearly state which ROM you are using and which kernel did work for you (which one did you use before).
To recover from such a scenario, boot into recovery and restore a backup of your working state. If you do not have a backup, and its the kernel fault, flashing your old kernel should solve the problem.
5. What min/max frequencies should I choose?
The short answer: min 176, max 614, if you have wake up issues up the min speed to 264 and then to 352.
To play with the speeds I suggest you install SetCPU (or similar app), so you can view and change your settings interactively. To change it permanently from the bootup see instructions on first post. You also use options like "Set on boot" in SetCPU if you prefer that.
The long answer:
The max frequency will effect the speed and responsiveness of your phone when screen is on. Note, that any speed above 528Mhz is above the specification of the manufacturer, hence is overclocking and could, in theory, shorten the life of your device. At high enough frequencies all devices will stop functioning, the exact threshold depends on your luck with your specific device. From my experience and knowledge, running at stable frequencies (or say one or two steps down to be on the safe side), should not harm your device - of course all overclocking is done at your sole responsibility.
As far as I know, almost all device can handle 652Mhz, most can reach the 691/710 area and some can even reach higher than the 748Mhz cap of this kernel. To find out which speed your phone supports, use SetCPU (or similar app), start from 614 for example and up the speed one tick a time. Don't select "Set on boot". At each step play with the phone a minute or two. If the phone gets stuck, reboot it (take out battery if necessary) and go one tick down.
Additionally, note the higher your max frequency the higher the battery drain will be when the screen is on. It is true that the display, data, wifi, gps, etc. should drain much more than the cpu. Still, I recommend staying in the sane frequencies range, no more than say 691Mhz (even if you phone can handle it).
Finally the min speed will effect standby battery life (when screen is off). From my experience there is a difference in battery life between 19Mhz and 352Mhz min frequencies but it is relatively small (much less than I expected). 19Mhz is not stable for me, almost stable, but over a period of weeks you will probably experience weird and possibly very rare instabilities. For me this was the when playing music with screen off the phone got stuck at 19Mhz (very hard to find this out), and became totally unresponsive until I rebooted it. Therefore, I recommend starting from 176Mhz, and if you have wakeup issues to bring it up. With 352Mhz you should have no wake up issues at all.
6. I am having wakeup issues (such as unresponsiveness to wakeup, weird coloring after wakeup, screen inversion, caller id not working on wakeup)
Up the min speed to 264 and then to 352. With a min frequency of 352 you should not have any wake issues.
See the FAQ #5 above for more information.
7. I am experiencing bad battery life with FlyKernel
First, please make sure to reboot the ROM at least one time after you flash the kernel. There have been reports that ROM/kernels behave badly on the first boot.
Personally, I do not do battery calibration, but if it makes you happy go for it. I do recommend at least charging the battery overnight, or a couple of hours after it has reached 100% to be sure it is full. Then use it, your regular usage for a few days and only then judge the battery life.
The battery percent indicator, over short periods of time seems extremely inaccurate and its very hard to reach any correct conclusions based on it.
If you do want to report bad battery life, please state your settings (kernel version, min/max speeds, governor, etc.), over which period you have been testing the battery, under what usage, what is the battery life you are used to having with which kernel and what is the battery life you are experiencing now.
Note, that roughly speaking, I lose less than 1%/hour when screen is off (wifi, data, gps, etc. also off), and about 10%/hours when just screen is on but phone does nothing at all (again wifi, gps, etc. off). About 20%+/hour when stressing my phone (although I have no data plan so can't test that). I am using the latest FlyKernel @ smartass 614/176.
8. What size should I give the swap partition?
short answer: 0.
long answer: I do not recommend using swap on the hero, hence 0. If you have a very fast SD card, and want to try it, give it say 64Mb. Note that I know of no ROM for the hero which activates swap automatically - you'll need to add a init.d script or something to activate it (see a bit more info here). Let me know if you find a scenario where the swap gives substantial improvement over no swap.
Finally note that FlyKernel versions before 12 do not support swap.
9. Should I use ext2, ext3 or ext4 for my ext partition?
Short answer: ext4. Note that FlyKernel versions before 12 did not support ext4, ext3 is supported since version 10.
Long answer:
Previously, I was under the impression that a journaling file system is a very bad idea for flashable storage. I still think its not ideal but better than the other alternative:
I have been using dual booting, placing an entire development ROM on an ext2/4 partition and using it for development. And when using ext2 it would get errors almost every boot and every couple of days get corrupted to the point I needed to manually restore damaged files to get it working....
It seems that if you only use it for app2sd, there are very infrequent changes to this volume (only when you install a new app), hence it does not get corrupted. But this also means that ext4, in this scenario, will not pay much overhead because there are very few changes. And in the case there are many changes, if I have to choose between a slightly shorter SD life with ext4 (and then I can finally get a faster one ) or risking my data getting corrupted on a daily basis with ext2 - I prefer the first (ext4).
Questions 10-13 are now obsolete with smartassV2 - see the first post for details about it
10. Do I need a SetCPU (or similar) screen off profile with smartass?
No, smartass automatically limits the screen on frequency to >= 518Mhz to ensure responsiveness, and screen off frequency to <= 352Mhz to keep standby battery life under control. Much like HTC's perfllock, it does this at the kernel level so it is much better than app level screen off profiles.
11. Using smartass the CPU frequency does not drop below 518Mhz (with screen on)
Intentional to ensure responsiveness. From my testing, when screen is on battery drain difference of speeds < 518Mhz is not significant relative to the drain by the screen itself.
12. Using smartass the CPU frequency does go above 352Mhz (with screen off)
Intentional to keep standby battery life under control.
13. Using smartass the CPU frequency is always at its max (or always at 352Mhz when screen is off)
See "Monitoring the CPU frequency" in the "Advanced subjects".
14. I am experiencing spontaneous reboots
Please post, in this thread, with as much detail as possible about the problem.
Please also attach the last_kmsg, which you can get from example using:
Code:
adb pull /proc/last_kmsg
15. What happend to the BFS version?
With the FlyKernel-12 scheduler tweaks (CFS scheduler), it surpasses the BFS version in every way. I tried to compile a BFS from the FlyKernel-12 code but even in neocore, in which the BFS was always much better, the new tweaked CFS leaves the BFS in the dust. Hence, I see no reason to continue and build/support a BFS version. The hero-bfs_defconfig is still up to date in my sources if anyone wants to build it themselves.
*. I am experiencing an issue not covered in the FAQ which I believe is kernel related
Please post, in this thread, with as much detail as possible about the problem.
Please also detail why you believe this kernel related. The best "proof" that it is the kernel's fault, is to flash back your old kernel and verify the problem is solved, then reflash the new kernel and verify the problem reappears. In any case please detail the kernel and version(s) on which your are experiencing the problem and those on which you do not.
Advanced Subjects
* Monitoring the CPU frequency
Will rewrite this more clearly. In the meantime:
http://forum.xda-developers.com/showpost.php?p=9925116&postcount=903
http://forum.xda-developers.com/showpost.php?p=9929325&postcount=919 <-- Mainly this one!!!
http://forum.xda-developers.com/showpost.php?p=9989996&postcount=970
http://forum.xda-developers.com/showpost.php?p=10010110&postcount=990

Change log and previous versions
FlyKernel-13
- Scheduler tweaks: use the scheduler settings that worked well on flykernel-11c and 12pre6 (tweaked them very very little), responsiveness should now be better than on the FlyKernel-12 release
- Backported the new smartassV2 - now the default
- Added interactiveX governor also
- A few config changes and compiler optimizations
FlyKernel 12a (mediafire)
- Fix wake up issues with new scheduler tweaks
- Smart update script: make noatime tweak option to (hopefully) solve boot problems
FlyKernel 12
- Smart update script
- Optimized scheduler parameters
- Fix Usb mass storage after usb tethering (at least on CM ROMs)
FlyKernel-12pre6
- Align ext2/3/4 config options
- Merge small fixes to lowmemorykiller module.
FlyKernel-12pre5
- Backport of smd rpcrouter to avs333 request.
FlyKernel-12pre4
- Partial fix for the lockscreen flickering when locked/unlocked rapidly (with smartass).
- Very small tweak to other smartass parameters.
FlyKernel-12pre3
- Fixed frequency table according to Radu's comments. Frequencies which are not on PLL2 have been removed!
- Tweaked smartass to spend more time at the lower frequencies to improve battery life. Also smartass's allergy to 19Mhz has been cured!
- Some configuration tweaks, mostly sleep related.
- 528Mhz frequency does not work well with OC, so it has been replaced with 518Mhz which does work fine.
FlyKernel-12pre2
FlyKernel-12pre2 optimized for CM based ROMs (default speed 576/352)
- Added compcache support
- Added 19Mhz and 264Mhz frequencies
FlyKernel-12pre1
- Lower voltages of high frequencies (>= 528Mhz)
- Added ext4 support (I currently use it for dual booting)
- Interactive updated (does anyone find it better than smartass? in what scenario?)
- Smartass fixes and optimizations - should be more responsive now and battery life should (hopefully) still be excellent.
- Camera backport from .32 (12pre1-cam32)
FlyKernel-11c
FlyKernel-11c #66 (Generic)
FlyKernel-11c-BFS #67 (Generic)
- Smartass: now wakeups up from sleep first at 528Mhz (no OC), to hopefully help with wake up issues.
- Bunch of fixes/optimization from CM espresso kernel and from Decad3nce (see github)
- BFS version
"Optimized Kernel Packages" (only for CM6 based ROMs: Floyo, Elelinux, Froyd):
Find the appropriate kernel for you by its name in the FlyKernel-11c directory
The naming conversion is:
flykernel-11c-CM-<min>-<max>.zip (with boot animation)
flykernel-11c-CM-<min>-<max>-nologo.zip (no boot animation)
flykernel-11c-BFS-... (BFS version)
FlyKernel-11
- New smartass governor (see technical detail below). Previous governors still supported.
- Added IPv6 (only for Google Googles?!)
- Fixes camera freezing CM6-based ROMs (thanks Ninpo for a "code cleanup" which fixed this )
- Fixes detection of USB connection during boot on CM6-based ROMs.
- Various squash-sets imported (see github)
- NORMALIZED_SLEEPER disabled.
FlyKernel-10a (rapidshare megaupload)
- Optimize some sleep/idle code (thanks to ninpo)
- Add module for IP header compression - hopefully this helps google apps (inspired by ninpo).
FlyKernel-10a-BFS (rapidshare megaupload)
- BFS version of 10a.
- Whats is BFS? see wikipedia and more details here.
FlyKernel-10
- Fixes for Froyo ROMs (FroydVillain and Elelinux)
- Added some more modules inside the kernel (notably using VPN should now work). I am now more aligned with the modules included in other kernels (well mainly ninpo's kernels), so hopefully you should not run into any missing modules.
I even added support for ext3.
- Generic update for all ROMs.
Flykernel-09:
FlyKernel-09 for VR12,RCMix,ChoclateEclair,Modaco and SuperHero
FlyKernel-09 for Kimera and Sensehero
FlyKernel-09 for MMod 1.2.3
FlyKernel-09 for FroydVillain and elelinux - Beware there are problems with 09 and Froyo ROMs.
FlyKernel-09 for CM6
- Added the excellent minmax governor.
- Removed interactive as it does not behave well at all - just use minmax
- added version which supports the 288M data partition - removed now since MAX appears to be fading out - just use dalvik2SD instead.
FlyKernel-08
FlyKernel-08 for Froyo and ASOP
Added Mike Chan's interactive governor, adaptation to Hero by Nadlabak and Ninpo. Added some tweaks of my own - now works well also with big frequency table.
Tweaked conservative governor for better performance.
Fixed/cleaned kernel co/nfig and modules - among other things iptables should work fine now.
Bigger frequency table.
FlyKernel-05 (BFS)
BFS version of the FlyKernel-04
FlyKernel-04
Based on HTC 2.6.29 official kernel source.
Includes patchset 2.6.29.6 and various fixes
Boot OC - Only for Sense based ROMs (The smart update script added in FlyKernel-12 provides a cleaner and better solution for all ROMs)
Boots very quickly by setting the OC speed right from the start. Also sets the original HTC boot animation which is quicker for most ROMs. Finally, replaces the 09zipalign with 09betterzipalign (again thanks ninpo).
Please have a backup before you try this, as there is no other easy way to undo this.
Select the update file according to the speed your phone can handle:
boot @ 653/160: http://www.multiupload.com/5RAXNJ7AWY (rapidshare megaupload)
boot @ 672/160: http://www.multiupload.com/RRQ0HYI8O8 (rapidshare megaupload)
boot @ 691/160: http://www.multiupload.com/20AJV7FLQI (rapidshare megaupload)
boot @ 710/160: http://www.multiupload.com/WHROUYNGQ6 (rapidshare megaupload)
Theoretically, this should now work on any ROM and any OC kernel. I have tested the 691 update on VR12 and Froyd 1.4 with my kernel and it works fine. Above files (now with "_" at end of name) updated to also work on ChocolateEclair and hopefully other ROMs on 31/8.
Note that in my recent kernel versions the lowest frequency is 176, so it will boot with a min frequency of 176.

cool.. will try. like the idea of overclocking before boot

can you post a diff file of what you modified?

diffs of which change?
there are a lot of changes and fixes, which range from fixes by me in the source code, to just copying/applying files from others.
I think it would be better to keep this thread open for issues and questions about the usage of these fixes. Still I will be more than happy to share anything I have done - please contact me with the exact change you are interested, either by PM or open a new thread if you think it is of general interest for developers.

There are literaly dozens of different kernels floating arround, all of which are always "brand new super fast ultra optimized". From a user perspective it's hard to tell which one is the best. I think this community needs more openness in the developpement. I think it would be a good habit if developpers posted their diff files (of everything) instead of just saying that they made "optimizations".
thanks for your work

zorxd said:
There are literaly dozens of different kernels floating arround, all of which are always "brand new super fast ultra optimized". From a user perspective it's hard to tell which one is the best. I think this community needs more openness in the developpement. I think it would be a good habit if developpers posted their diff files (of everything) instead of just saying that they made "optimizations".
thanks for your work
Click to expand...
Click to collapse
Trying it out might help in deciding which is the best for you. There is no such thing as an absolute best, sorry. To each his needs and his preferences. I also included a convenient undo update script which restores the original kernel.
Personally, I am not aware of any other kernels for the VillainROM (except the original one by ninpo) and for me my kernel works better. Additionally, I have gotten very good feedbacks for my kernel and fixes on iandroid (using HebVillain which is very tightly based on VR12). So I thought others here might want to try it and maybe would also like it. Please also feel free to bash it, but please try it first and then reply with comments which I can relate too.
Finally, I am all for complete openness: If you are really interested in the kernel sources, you can find them along with all my changes here which could be of great to help to you especially if you want to compile the hero kernel yourself. In such a case I would recommend starting from here. The biggest other change is the RTL fix, for which you find the diffs here (it is verses the eclair branch of the android source code). As for the other files & changes I did, I have tried to detail as much as possible in my original post.
Feel free to contact me (also by PM) if you want more info or help.

I just installed your Kernel and the Boot Optimization and brother my phone is flying!!!! GREAT JOB!!!
100% recommended flash for your VR12
THANKS!!!

yep!
all great! you are the MAN =)

good work erasmux, does it work with Arabic language with Arabic fonts installed ? I mean connected letters
Thanks a lot

I hope it does. I don't use Arabic, but if there are problems, report them and I'll do my best to fix them.

Good job erasmux!

Problems for me.....
Installed Kernel & Optimization and Boot time optimization
Made all my icons go to pot,
"problem loading gadget" on powerbar,
"problem loading gadget" on Battery Meter Widget
Game Icons, CoPilot live, System Widget all showing default app icon.
Lost a WHOLE LOAD of installed apps, simply not there listed any longer. So many gone I can't recall what I have lost.
Tried the undo file Original VR12 Kernel:
Got my apps back but still probs with some widgets, boot screen remained the HTC one (didn't revert to the villian screen)

First, I have fixed the kernel restore file in the original post to also restore the original villain boot animation, note that the new file is called: V12-RestoreKernel_.zip (with additional _ at end)
Thanks, for the remark.
Regarding the apps, that is very weird. Did you get these "problem loading gadget" on the screen or where? A logcat from the start of the boot would be very helpful (although I can understand if you don't want to flash it again just to help me debug...).
Regarding the widgets (when the apps do appear) ,try clearing the HTC Sense data (unfortunately this will reset your desktop but it should restore your widgets and its better than having to reinstall everything).

I'll have to have a go later.. tied up at the mo..
Prob loading gadget appeared on the screen (still does).
Will try clearing sense and post back later.
EDIT: Clearing Sense worked. Thanks.

made battery callibration (http://www.villainrom.co.uk/viewtopic.php?f=97&t=1789&start=20#p19769).. full charge (~17:15).. after 5 hours using phone.. 5-7 calls (1-5min each), 30 min wifi and playing =) and now ( 22:40) 99% battery!!! blja, im very happy!!!!!!!!!!
cpu always 245-576mhz
only like with original VR12 kernel after few hours of use at 576mhz linpack score down from 2.5 to 1.8 , but after installed autokiller ( preset 60mb) it's always 2.45-2.57
now i think VR12 the best!
Thank you one more time! will write back tomorrow eve =)

is this included stuff really usefull or it can be disabled?
ipv6 (lot of different options)
LZO and ARC4 crypto stuff
extra PPP stuff (MPPE, PPPOLAC, PPOPNS)
DSCP and TCPOPTSTRIP
INET_TUNNEL
XFRM_IPCOMP
CPU_FREQ_GOV_CONSERVATIVE
the /proc/config.gz (kernel .config support)
Also, I noticed that the device boot with mem=64M. Does it mean that the rest of the RAM isn't used?

AFAIK the only way to change this is to recompile the kernel.
Many of what you said I saw requests here on XDA that kernel developers add (there applications which use it). Please note that many of those modules do not automatically load and need to be manually loaded so they should not have any effect.
Others stuff, mainly the IPv6 stuff i doubt anyone uses - must have "inherited" it from the config i used as a base. I will look into it for future release if I can remove that stuff.
About the mem=64 I am not sure what that is, my phone is definitively using the full memory. I will also try to understand and possibly adjust that for future releases.
Thanks for the input.

An other question, is a kernel really tied to a specific ROM? I have VR12 right now so I could try it, but I was also thinking of upgrading to a 2.2 ROM.
About the modules, I think that most of the stuff that I noticed was compiled in (=y) and not as modules (=m). If they are only used by 1% of the users, I think it would be better to have them as modules and make sure that they don't load automatically at boot.
Also, do you know if it is better to have a small frequency table (with, let say, only 3 choices) to avoid excessive frequency switching?
Is the dalvik to SD trick included worth it for those of us with the original 2GB SD card?

[KERNEL] SpeedMod Froyo [K13E HPCall VoodooSnd7 SharpnessFix STABLE]

Hi people. This kernel aims to be fast, compatible, stable, and have good battery life. It makes our Galaxy S run the way it should.
This kernel is for the International Galaxy S (I9000) and Bell Mobility Vibrant (I9000M)
The SpeedMod kernel for the AT&T Captivate is available here: http://forum.xda-developers.com/showthread.php?t=893880
Note: Only lagfixes using EXT4 are robust. Other lagfixes run the risk of data loss on freezing, hard-reboots, or sudden power loss.
WARNING: Before you try any lagfix, make sure that you have enough free space on your Internal SD. You should have at least more free space than data+dbdata+cache combined.
Latest K13E (12-Apr) - Voodoo Sound v7. Lowmemorykiller fixes. Improved display sharpness using AMOLED processing mode in MDNIE. Support for voice calls through headphones. Check here for more info and downloads.
>>> Click here for the installation procedure using Odin.
>>> If you have questions, please read the FAQ: Frequently Asked Questions first!
>>> What is the SpeedMod kernel?
Latest features:
- Compiled using codesourcery 2010.09: Faster and more battery efficient
- The only properly working Tiny RCU implementation, thanks to Paul McKenney
- More efficient: Removed debug logging from kernel and Android
- Most updated version of my Enhanced Universal Lagfix fork with improved stability
- Full Android 2.2.1 ROM compatibility
This kernel has:
- Based on JPX Android 2.2.1 kernel source
- Works on all stock Froyo 2.2 and 2.2.1 ROMs and popular custom ROMs
- 340MB RAM
- Enhanced version of sztupy's Universal Lagfix
- Includes neldar's BackLightNotification 2.3 from https://github.com/project-voodoo/backlightnotification/tree/master/kernel_patches/
- Sharpness (AMOLED mode) & color fixes for the screen
- SpeedMod: Replaced kernel jhash2 with jhash3
- Includes my Startup Tweaks from http://forum.xda-developers.com/showthread.php?t=813309
- Adjusted kernel HZ value to improve smoothness
- Uses BFQ IO scheduler by default, from http://algo.ing.unimo.it/people/paolo/disk_sched/sources.php
- Updated ext4 code in kernel from http://www2.kernel.org/pub/linux/kernel/people/tytso/ext4-patches/
- Properly working Tiny RCU for better speed and efficiency from http://android.git.kernel.org/?p=ke...it;h=9b1d82fa1611706fa7ee1505f290160a18caf95d
- Patched lowmemorykiller for compatibility with Tiny RCU from http://android.git.kernel.org/?p=ke...ff;h=5545554aac04918ece318270d63cbfcb015577a9
- Optimized compiler flags: -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp
--------------------------------
FOR BEGINNERS:
This kernel is based on sztupy's Universal Lagfix: Lagfix and root options are accessible by booting into the Recovery Menu.
To get the best speed, it is recommended that you enable all Tweaks from the Recovery Menu. Tweaks are under SpeedMod features. Info on Tweaks: http://forum.xda-developers.com/showthread.php?t=813309
How to root: http://forum.xda-developers.com/showpost.php?p=8896862&postcount=90
Kernel HZ value: HZ=500 is smoother, HZ=256 is Samsung default.
--------------------------------
Memory configs (K10J and later):
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM=2048
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_GPU1=4096
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_ADSP=1500
CONFIG_WLAN_SAMSUNG_MEMSIZE_BCM=256
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=12288
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=12288
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=32768
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=32768
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=10240
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMD=3072
Memory configs (K10I and earlier):
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM=4096 *#
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_GPU1=8192 *#
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_ADSP=1500
CONFIG_WLAN_SAMSUNG_MEMSIZE_BCM=256
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=11264 **
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=11264 **
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=30720 ##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=30720 ##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_JPEG=1024 *#
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=6144 ^^
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMD=3072
** FIMC0/2 = Below this and 720P video recording won't work
## MFC0/1 = Below this and 720P video playback won't work
*# PMEM/PMEM_GPU1/JPEG = Taken from default values for Galaxy Tab
^^ TEXTREAM = Too low and 3G video call stops working
THANKS: Big thanks to sztupy for his kernel compiler VM and ULFK, lastufo for testing compiler optimizations, ykk_five for testing memory configs, and others who gave ideas or helped.
--------------------------------
WARNING: If you use a custom boot animation, apps like One Click Lag Fix will not work because it disables the playlogos1 script hack.
The files with ending with -CWM are for flashing using Clockwork Recovery.
These other zip files are for flashing with ODIN.
--------------------------------
About USB Mounts:
>>> Click here to download the USB mount fixes. Latest SpeedMod versions do not need this fix. The fix is for using K12E or older with 2.2 ROMs. It fixes the problem where Internal SD mounts as a read-only drive on the PC, or if the External SD does not get mounted.
>>> If you have questions, please read the FAQ: Frequently Asked Questions first!
>>> CLICK HERE to DOWNLOAD the kernels.

Thank you! very useful..

Sounds good!
Could it be used in conjunction with Doc's ROM?

Implementing this in my next "Darky's Raw Steel Edition v3.1"

Cant wait. How about version A3 - O3, standart HZ (or 200, which ever you think is better) and OC (sources are already out)?
For now this is the ultimate kernel, without a doubt.
Btw, tried out HZ 100 quite extensively last night (plus ext4-ext2 and all tweaks). It is indeed not as smooth (with 6 pages of widgets in launcherpro, maximum memory consumption with 100 HZ - when you go to screen previews first drawing is slightly laggy. Without 100 - it is smooth on first attempt).
Battery life.. Well, subjectively - better, I would even say much better. But it needs more testing.

Startup script speed tweaks
# Tweak cfq io scheduler
Tweaked settings of the disk io scheduler more for flash memory. Defaults are optimized for spinning harddisks. Lowered the idle wait, re-enable the low latency mode of cfq, removed the penalty for back-seeks and explicitly tell the kernel the storage is not a spinning disk.
# Tweak kernel VM management
Set tendency of kernel to swap to minimum, since we don't use swap anyway.
Lower the amount of unwritten write cache to reduce lags when a huge write is required.
Increase tendency of kernel to keep block-cache to help with slower RFS filesystem.
Increase minimum free memory, in theory this should make the kernel less likely to suddenly run out of memory.
# Tweak kernel scheduler
Make the task scheduler more 'fair' when multiple tasks are running. This has a huge effect on UI and App responsiveness. These values (less aggressive settings) are 20% of the Linux defaults, and about half of the Android defaults.
# Miscellaneous tweaks
Manually set the starting dalvik heap size.
Increase wifi scanning gap to reduce battery usage.
@ Hardcore can you paste your Startup Reference, on your post too for a quick Faq for ppl here, looking for details on the tweaks.
Thanks

Ferdimage said:
Startup script speed tweaks
# Tweak cfq io scheduler
Tweaked settings of the disk io scheduler more for flash memory. Defaults are optimized for spinning harddisks. Lowered the idle wait, re-enable the low latency mode of cfq, removed the penalty for back-seeks and explicitly tell the kernel the storage is not a spinning disk.
# Tweak kernel VM management
Set tendency of kernel to swap to minimum, since we don't use swap anyway.
Lower the amount of unwritten write cache to reduce lags when a huge write is required.
Increase tendency of kernel to keep block-cache to help with slower RFS filesystem.
Increase minimum free memory, in theory this should make the kernel less likely to suddenly run out of memory.
# Tweak kernel scheduler
Make the task scheduler more 'fair' when multiple tasks are running. This has a huge effect on UI and App responsiveness. These values (less aggressive settings) are 20% of the Linux defaults, and about half of the Android defaults.
# Miscellaneous tweaks
Manually set the starting dalvik heap size.
Increase wifi scanning gap to reduce battery usage.
@ Hardcore can you paster this Ref on your post too for a quick Faq for ppl here, looking for details.
Thanks
Credit: Extralife (for pasting on another thread)
Click to expand...
Click to collapse
Thanks mate, very informative.

Ferdimage said:
Credit: Extralife (for pasting on another thread)
Click to expand...
Click to collapse
These tweaks are actually by hardcore, and his explanation =))

Any chance of incorporating the 1.2Ghz overclock?

Very interested in A1 gonna try it out when im home. I preffer speed over battery ^^

You actually changed any code in the source. Or just in config and compile flags? Want to compile kernel (voodoo sources) with this.
Sent from my GT-I9000 using XDA App

dereknas said:
Any chance of incorporating the 1.2Ghz overclock?
Click to expand...
Click to collapse
+1
Hope you could compile with the latest alpha OC using http://forum.xda-developers.com/showthread.php?t=822027
EDIT: Seems raspdeep already has this on his OC kernel, trying

Will this work on stock JP6?

_Rayearth said:
Will this work on stock JP6?
Click to expand...
Click to collapse
yes
10 char

dupel said:
yes
10 char
Click to expand...
Click to collapse
Kewl!
Looking forward to it

mms will fc when I receive or send mms. I think it has to do with the jpg memory size?

zenkinz said:
mms will fc when I receive or send mms. I think it has to do with the jpg memory size?
Click to expand...
Click to collapse
Thanks for the feedback. I'll test it. UPDATE: Just tested sending MMS with Image. It works for me.
BTW, files uploaded!

Can you post some details about jhash3? What's the gain?

First Impression with O2 and HZ=500. It is just me or it is waaay much smoooother the user interface? The scrolling and even opening applications experience feels closer my old HTC Desire.
Let's see battery life, but something changed with this latest kernel (Have been using your ones from the other thread).

Hi! Who can explain to me what is the difference miz these compilations nucleus.
Phone now works flawlessly. It should change or not???
http://forum.xda-developers.com/showthread.php?t=811660

[REF][SCRIPTS] Android Optimization Tips - i9000 (UPDATED 1/10/12)

Attention!
If you're looking for scripts, here it is:
[CWM][SCRIPTS][TWEAKS] Thunderbolt!
Script Reviews are here:
Script Reviews
Introduction
I've been meaning to share this with the whole Android community. It seems unfair that only the i9000 folks have access to the vast research that I've done so far. Hence I'm sharing this in the general Android thread in hopes that it'll benefit everyone in the long run
A lot of people often asked about how Android really works and the optimizations can be made to their Android to make it perform better in terms of:
- battery life
- raw performance
- GUI smoothness
With Android based on Linux, and with the experience I have with Linux/Unix (I deal with Unix/Linux on a daily basis for my work) I managed to find some tweaks that we can do to optimize our phones.
I also hope that people will experiment with the tweaks posted here and feedback to me if there are certain ways that I'm doing incorrectly or there are better ways than what I've posted here.
Script tweaks
There are a lot of scripts in XDA that specifically uses the optimizations (Linux or Android based) that I will explain below to actually increase performance/battery life. However, you need to know what those scripts do before using it.
I've done some reviews of the script here:
Script Reviews by Pikachu01
There are good scripts that are properly tested and made sure that it works. It's a script by Zacharias maladroit, the kernel dev who makes the platypus kernel for CM7 and snail kernel for i9000. I modded it to be compatible with i9000 and it'll probably do more than some of the scripts I reviewed
From there, I've also taken the liberty of modifying it some more based on my knowledge and research I've done. It's called ThunderBolt!:
LINK
Now onwards to what actually goes on beneath the hood.
Android Governors
Some custom kernels provide customized governors for you to choose. These are currently known:
- Ondemand (CPU scales to the highest frequency immediately after a certain CPU threshold)
- Conservative (CPU scales to the highest or 1 scale lower than that after a certain threshold gradually and scales down if CPU is below a certain threshold
- OndemandX (Has sleep codes that scales down the CPU when device is asleep. Threshold is set to scale slower)
OndemandX
OndemandX has a suspend frequency that it maintains when the phone is sleeping. It does have a known issue of waking up too slowly when a call comes in.
Conservative
Conservative is used when you would like the CPU to scale to the maximum through each frequency slowly before reaching the maximum. It saves more battery at the expense of smoothness. There are a few tunables that can be configured in Conservative governor, namely the freq_step and both the up and down thresholds.
freq_step is a tunable that determines how much frequency (a percentage of the maximum frequency of your device) to increase at each sampling rate. e.g. you have 5 as freq_step and your maximum frequency is 1GHz. At each sampling rate, it'll increase by 50MHz. If your current frequency is 100MHz, it'll increase to 150MHz at the next sampling. What if your device doesn't support 150MHz? This is done by splitting time between 100MHz and 200MHz (assuming your next frequency is 200MHz) so that in average, your phone is performing at 150MHz.
The up_threshold is how much threshold to wait for before increasing the base frequency to the next freq_step. I.e. if it is 80, the CPU will wait until it is 80% loaded before increasing the frequency. The down threshold is the opposite of up_threshold, which is the threshold to wait until the CPU downscales the frequency to the next frequency step.
Ondemand
Ondemand is a governor that basically a simpler version of conservative. One difference is that it scales to the maximum frequency after load has exceeded a threshold. This is usually 80. After that, it looks at the load again when it's at the max frequency. If it's below 80 (example), it'll scale down one frequency step. The frequency step mentioned here is the available frequency step. I.e. if your device has frequencies of 100,200,400,800 to 1GHz then it'll scale down from 1GHZ to 800, 400 then 200 and 100.
One optimization I have for Ondemand for i9000 TalonDev is that I tuned it to be 80 rather than 65. I have not felt any slowdowns from using this setting and it saves a tiny bit more battery. You can experiment on this value however you want, but bear in mind that I'm not responsible for any slowdowns or damage that is caused by it. Read up a bit more on thresholds to know more (Google it).
I/O scheduler tweaks
Another tweak that can be done is the I/O scheduler tweak. Some kernels come with a few standard I/O schedulers while others have extra schedulers that you can choose from. I'll explain the few that I know and if you have more information on the schedulers, you can post it here for everyone to discuss/share
CFQ - Completely fair. Most will come with this, but this is not optimized for android. Some kernels do optimize it and use it.
Noop - Simple and least overhead of all I/O schedulers. Produces the best outcome for some cases and some do swear by it. It's downside is that it is easily bogged down by high I/O transactions.
Deadline - Optimized for mobile-like devices like Android. Also, some do swear by this. If its writes_starve sysfs is tweaked to be fair, it's the same as SIO.
SIO - It's a fair deadline scheduler. It's the best scheduler. Nuff said.
VR - A newer I/O scheduler that places penalty on reverse seeks. Not for flash drives, though the R penalty can be tweaked to be a multiplier of 1. Even if this is done, it has a high overhead.. Read more here: http://www.gelato.unsw.edu.au/IA64wiki/IOScheduling/VRscheduler
BFQ - Too high of an overhead, it is optimized for spindle disks.
You can pick and choose from Voltage Control or other UV/OC apps and apply it immediately to feel the difference.
Here's my assessment of all the schedulers that I know:
SIO> NOOP> Deadline > VR > BFQ > CFQ
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.
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.
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.
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.
BFQ has a lot of algorithms to make sure each process gets a fair slice of bandwidth (Budget Fair Queueing). Too much overhead.
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.
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.
LowMemoryKiller
The LowMemoryKiller is a constant debate between more free RAM and more multitasking capabilities as free RAM (more than 60MB free) is actually wasted RAM. The fact is SGS only has a puny amount of RAM left after a few big chunks are allocated to the Graphics, Modem, Sound and Video (and some others that I do not know a lot about). With that knowledge, Samsung decided to give the SGS SL a bigger amount of RAM when they released it ( about ~650MB of RAM read that from somewhere, can't remember).
The LowMemoryKiller is actually a feature in the Android OS for better memory management.
You can read about it more here:
http://forum.xda-developers.com/showpost.php?p=5442369&postcount=1
This is an important feature due to the perennial problem of having low free memory causing lagginess and slowness in launching apps. When you have free memory lingering around the number of 40MB or less, the Android OS just lags like hell.
What this would mean is, you would want to tweak the LMK to not have the situation of it having less than 40MB (or even close to that).
The modern Linux machine in the Android ecosystem relies on a mechanism called Low Memory Killer (LMK) to consistently free up RAM. This is due to Android's internal mechanism of caching apps (and never fully exiting them) when you press the back button. This is to enable faster app switching and provide a seamless experience for apps usage model. Android also, by itself will also constantly look for often used apps to cache them for faster app opening. This will happen even before your system fully boots.
Now, when you mention LMK, the most obvious thoughts that come up are minfrees and Out Of Memory (OOM) groupings. Yes, those two are integral parts when it comes to LMK. The issue here is that no one actually mentioned that there are two LMK systems in Android, that being:
- Linux LMK
- Android Dalvik VM LMK
Both are separate entities that kills/removes app/dalvik cache from RAM when RAM reaches a certain level.
What confuses most people (including me) is that the OOM groupings of both mechanisms have the same names being (Android 2.3 based):
LMK App Categories
FOREGROUND_APP: Your apps in the foreground, being used currently, interfacing with the user.
VISIBLE_APP: Visible app that is still viewable by the user, but not interacting with the user, example could be apps that reside in the status bar, and giving live information i.e. Os monitor graphs.
PERCEPTIBLE_APP: App that the user can still perceive i.e. Music app that is playing music.
HEAVY_WEIGHT_APP: RAM heavy apps that are not being interacted with, but will be a pain to load if its information is cleared in the memory.
SECONDARY_SERVER: App that acts as a secondary server. Not sure what this really means, but client-server thingy but secondary? Could be something that syncs with an app, but is not syncing currently?
BACKUP_APP: App that is currently making a backup (like Titanium backup?)
HOME_APP: Your launcher.
HIDDEN_APP: An exited app that still significant residual memory in the RAM. Exited only some time ago, or is constantly used by the user.
EMPTY_APP: An exited app that only has small remnants of residual memory in RAM. App that is exited quite some time ago.
Take note that this is my understanding of the OOM groupings. If there are mistakes, please correct me
Tuning LMK
Both the LMK and Dalvik VM has this groupings and they can be tunable by using prop and lowmemorykiller/parameters/adj respectively.
One errata about this is that the Dalvik LMK has one extra tunable which is CONTENT_PROVIDER, which affects widgets that are not currently refreshing or displaying information. The ADJ (which I will explain later) is not available to be tuned though. And it is clearly missing from the Linux LMK.
The ADJ is the so-called priority of the app categories, with 0 being the highest (should not be killed) and 15 being the lowest (should be the first to be killed). I haven't seen values other than 0-15 but I have a feeling that the numbers are arbitrary, and can be extended up to 65535, but who would want to do that since they're only 9 app categories
LMK are specified by pages, with memory = 4 * pages.
e.g.
4096 pages represents 16MB RAM (16 *1.024)
From the Linux LMK source code, the parameters can be adjusted as such:
Code:
* For example, write "0,8" to /sys/module/lowmemorykiller/parameters/adj and
* "1024,4096" to /sys/module/lowmemorykiller/parameters/minfree to kill processes
* with a oom_adj value of 8 or higher when the free memory drops below 4096 pages
* and kill processes with a oom_adj value of 0 or higher when the free memory
* drops below 1024 pages.
Take note that the oom_adj so far takes only 6 values (although I am confident that it can take more than that). Haven't experimented enough to validate that, but I shouldn't need to as assigning different oom_adj should be a given for all the app categories. This is to make the LMK intelligent enough to determine which app to kill first rather than grouping different app categories into one priority, in which a lot of popular LMK settings that devs provide do that.
And for the Dalvik LMK, my understanding is that it will remove all dalvik caches of <INSERT_APP_CATEGORY_ADJ> or higher if free RAM/pages reaches the level specified.
Hence, two things are learned here:
- Linux LMK will kill an app category of that particular RAM level or higher if free RAM drops below a certain level e.g.
Hidden_APP has a minfree of 16384 pages. If pages fall below this level, Empty_App will be killed first, free pages is recalculated, then if RAM is still below that, Hidden_Apps will be killed next.
- Dalvik LMK will clear all dalvik caches in RAM of all the App category if free RAM reaches the level e.g.
SECONDARY_SERVER_MEM is 8192 pages. When RAM reaches 8192 pages, all SECONDARY_SERVER caches are cleared.
Best Practices
Now, how do we tweak both so that it is efficient in doing its job, i.e. LMK.
From my experiments I can safely say that:
- Below 60MB free RAM you will feel lag 5-10% of the time.
- Below 52MB free RAM you will feel lag 5-15% of the time.
- Below 46MB free RAM you will feel lag 15-20% of the time.
- Below 42MB free RAM you will feel lag 20-50% of the time.
- Below 36MB free RAM you will feel lag 100% of the time.
The experience of lag increases exponentially from 60 down to 36MB. Hence, the LMK should be tweaked against that.
Also, it is considered best practices to group oom_adj settings of Linux LMK with the Dalvik LMK as when free RAM drops to that level, both the Linux LMK and Dalvik LMK will work together to free up at both sides.
The 6 oom_adj that can be tuned for Linux minfree also need to be tuned correctly, failing this would make the LMK too aggressive/under aggressive in mid levels (even if your EMPTY_APP is aggressive, if your oom_adj is selected incorrectly, you'll get to a point where memory leak occurs).
Talon LMK - This is obsolete, TalonDev is using ThunderBolt! LMK from 0.5.x
Take for example, the Talon default LMK setting where:
LMK_ADJ is 0,1,2,3,7,15.
It's EMPTY_APP is 15
It's HIDDEN_APP is 5
It's HEAVYWEIGHT, SECONDARY and BACKUP is 3
Last three values of MINFREE is 4096, 9216, 12288.
Where's the issue here? If you noticed it congrats.
If you didn't, here's the issue:
The minfree 12288 is tied to EMPTY_APP which has a OOM_ADJ of 15.
The minfree 9216 is tied to nothing but has a OOM_ADJ of 7
The minfree 4096 is tied to HEAVYWEIGHT,SECONDARY and BACKUP with the OOM_ADJ of 3.
The LMK_ADJ is important as it represents the checkpoints where the Linux kernel will check for minfrees and kill them. Here's a situation:
Memory is below 12288 pages, OOM is triggered and Linux looks for EMPTY_APP to kill and kills all of them. Job done. Memory is back to >12288 pages.
After a few days, memory is below 12288 pages again, OOM kills all EMPTY_APP, but free memory is still lower than that. It sees if the next checkpoint is fulfilled, which is 9216 pages, and yes memory is still below 9216 pages. It looks for an OOM_ADJ of 7 and above to kill, but fails to find any as 7 and above OOM_ADJ only consists of EMPTY_APP.
Here comes the quandary. The next checkpoint is 4096. We're not ever going to reach that as you'll need memory to fall below 16MB, and at that time it'll be super sluggish to even support GUI. Hence BAM, memory leak or lag or something.
Supercharger LMK 512HP - Multitasking
Let me just paste this to avoid a lot of retyping
Code:
FOREGROUND_APP_ADJ=0
VISIBLE_APP_ADJ=4
PERCEPTIBLE_APP_ADJ=2
HEAVY_WEIGHT_APP_ADJ=5
SECONDARY_SERVER_ADJ=6
BACKUP_APP_ADJ=7
HOME_APP_ADJ=1
HIDDEN_APP_MIN_ADJ=8
EMPTY_APP_ADJ=15
FOREGROUND_APP_MEM=1536
VISIBLE_APP_MEM=3072
PERCEPTIBLE_APP_MEM=1024
HEAVY_WEIGHT_APP_MEM=10240
SECONDARY_SERVER_MEM=10240
BACKUP_APP_MEM=15360
HOME_APP_MEM=1024
HIDDEN_APP_MEM=15360
EMPTY_APP_MEM=25600
LMK_ADJ="0,4,6,8,14,15"
LMK_MINFREE="1536,3072,10240,15360,20480,25600"
A few things here:
It's EMPTY_APP and HIDDEN_APP is too large, 80 and 100MB respectively, but the 80MB is a false flag hence it doesn't really matter if you tweak that and you can get a very minor degree of multitasking because of this false flag. I'll get to that in a moment.
It's PERCEPTIBLE_APP has higher OOM_ADJ than VISIBLE_APP (odd selection, but RAM rarely goes below 40MB before it starts lagging like hell) People would reboot their phones when it gets to that, but it rarely gets to that for this configuration as LMK is pretty aggressive here.
Now, it's LMK_ADJ is "0,4,6,8,14,15"
15 is EMPTY_APP,
14 is nothing
8 is HIDDEN_APP - it looks like it'll only kill HIDDEN_APPs when it reaches 60MB, with HIDDEN_APPs being the heavy hitter of apps as most apps will end up in this category. Hence why multitasking is still doable (to an extent) but an aggressive LMK means taking a call or switching to a browser will kill your game (losing saves). Inconvenient, but it works for some people who haven't played a long game without saving and never took a call in between. Imagine the horror LOL!
Juwe's RAM Script
Code:
if [ -e /sys/module/lowmemorykiller/parameters/adj ]; then
echo "0,1,2,4,6,15" > /sys/module/lowmemorykiller/parameters/adj
fi
if [ -e /sys/module/lowmemorykiller/parameters/minfree ]; then
echo "2560,4096,5632,10240,11776,14848" > /sys/module/lowmemorykiller/parameters/minfree
fi
No OOM_ADJ are given, hence the stock ones are in effect here.
From init.rc, this is the stock 2.3.5 OOM_ADJ.
FOREGROUND 0
VISIBLE, PERCEPTIBLE 1
HEAVY_WEIGHT, SECONDARY_SERVER, BACKUP 2
HOME 4
HIDDEN_APP 7
EMPTY_APP 15
This one also suffers from the false flag of the 2nd last minfree not being used. It will start killing HIDDEN_APP at 40MB, which is usable (you'll only get lags 15-20% of the time, and most probably after long usage). Other than that, it's pretty stable.
Misc
There are a few known scripts that tweaks the LMK as well as the app priority (yes, the priority of the process categories can be changed too by using setprop.)
Supercharger is one of them:
http://forum.xda-developers.com/showthread.php?t=991276
Take note that Talon doesn't permit Supercharger to be used (it will override it when booting through boot scripts) as Talon itself uses its own LMK settings that are optimized for ZRAM/Swap.
Kickasskernel script is also included in Supercharger. The script will clash with Zach's script in ThunderBolt! too as both of them tries to set different values for the same settings.
Note that Zach's script doesn't tweak LMK settings as i9000 Talon doesn't permit it. With that, if you're using Zach's scripts, you would need to find other ways of tweaking the LMK. Using Auto Memory Manager is good. You can download Supercharger, look at the presets and apply it using Auto Memory Manager. The preset is the only thing important here
LMK App Category Priorities
Using setprop, there is a way to set the priorities of the category. Since, app categories are different, I can only offer one recommendation: The HOME_APP_ADJ.
This prop setting sets how high of a priority your launcher is. A 1 or 2 is sufficient to make sure your launcher doesn't get killed. However, do you really want it to be on 1 or 2. Based on the previous article (LMK/OOM), you would know that OOM priorities are comparatively based on one another. Setting it 1 or 2 in stock 2.3.5 values would basically override PERCEPTIBLE/VISIBLE app priorities. Do you want your launcher to be killed only after your keyboard/music player to be killed? You decide
Journaling/Barriers
This has been a touchy subject here in XDA for most people who debate about it. Most recently, the SAS/Acid tweaks included a way to disable journaling on these partitions:
/system (System is read only, it's safe to remove journaling. However, you will not see speed increase by removing it as you're not writing onto /system 99.99% of the time unless you're using Titanium backup to remove system apps or copying init.d scripts to it)
/cache (Cache can be rebuilt on the fly. Data corruption on it is not game breaking)
/data (All of your data on your phone is here. Removing journaling can risk data corruption. Read more below)
On whether we need journaling or not, I will pose this situation:
Journaling is required to maintain data consistency in events that could lead to data corruption. Data could get corrupted in a number of situations:
- Misbehaving app that constantly writes without syncing/committing data to the disk
- Power loss due to forced reboots or bootloops when data is partially written/committed into disk
Android will normally buffer its writes before committing to the disk. This way, data stays in the RAM before data would only get written into the disk after a period of time. Take note that we as Android enthusiasts seek ways to better our phone to get the most out of it through experimental and sometimes wacky ways. Take OC/UV for example. When we OCed or UVed too much, sometimes our phone will get deadsleep or constant reboots. This leads to corruption if journaling is not turned on. However, we can get corruption too even with journaling but the risk is smaller.
Mount options too, play a role in whether journaling can be safe/unsafe. Most lagfixes will place a "barrier=1" in the /data to make sure that journals are actually committed before an out-of-order write is done. With that, the risk is greatly reduced at the cost of performance. You could experiment by removing barriers and see if it works for you. No guarantees on data if you remove barriers! More info on ext4/barriers:
http://lwn.net/Articles/283161/
http://kernelnewbies.org/Ext4#head-25c0a1275a571f7332fa196d4437c38e79f39f63
If you do disable journaling, make sure to manually run an fsck on your disk. Make sure the fsck binaries are in your binary paths (echo $PATH to show your binary paths). Don't ask how to do this if you're unable to do fsck. It is your own risk that you are disabling journaling/barriers.
One experiencing I would like to relate is this:
I've personally disabled ext4 journaling on my device. After experiencing a sudden power loss (forced reboot), my apps started FCing left and right and device became unstable that it sometimes rebooted when the device is sleeping. In other words, it's a lost case. Reflashing was the only way to restore my phone. This happened 1 day after disabling my journals.
Also note that ext2 is basically an ext4 without journaling. However, ext4 is updated all the time while ext2 source is not updated for quite some time (2 or 3 years?). Most optimizations are already in ext4 while ext2 even without journaling is slower than ext4 without journaling. A comparison of performance:
No journal:
ext4 > ext2
With Journal:
ext2 (can't do journaling in ext2) > ext4 > ext3
Update: Attached is a JournalingOn.zip for i9000 only that you can flash to rejournal your partitions (Only for i9000 devices!). Also attached is Acid Tweaksv6 - Removed Useless Stuff that will disable journaling only for /system and /cache, if anyone is interested. You will need to rejournal first before unjournaling. To be sure that /system and /cache has no journaling and your mounts are applied correctly, type "mount" without the quotes.
You'll be able to see that /data will have:
Code:
barrier=1, data=ordered
/system and /cache will have:
Code:
barrier=0, data=writeback
To be really sure, you can check by using tune2fs included in both the JournalingOn.zip and Acid Tweaksv6 - Removed Useless Stuff.zip.
Copy the tune2fs to /tmp and set rwxr-xr-x as its permissions using Root Explorer/File Expert
Code:
/tmp/tune2fs -l /dev/block/mmcblk0p2 | grep features
You can substitute the /dev/block/mmcblk0p2 (which is /data) to /dev/block/stl10 (/dbdata) /dev/block/stl9 (/system) /dev/block/stl11 (/cache) to check each partition.
Continued in Post #2 - Lack of space
Still posting ...

Question
I guess this is safe too on a deodexed ROM, too freeze those bloatwares u listed?

Page 2
Undervolting/Overclocking
This is also another touchy subject, but more towards people complaining about phones that get forced reboots or bootloops. OCing is done to get better performance on your android. WARNING: Ocing will cause more wear and tear on your CPU and will reduce your CPU lifetime. How much it will reduce it? No one knows. It depends on how sturdy your CPU is, and that cannot be measured by any means. It could be reducing months out of year e.g. 6months out of 3 years? No one actually knows.
UVing on the other hand reduces battery drain especially when you UV your 100MHz as 90% of the time in normal usage, your CPU will idle at 100MHz. How much can it save? No one actually did a benchmark on it. Save to say, UVing does not harm your CPU, it will actually extend the life of it by reducing wear and tear Oh, bootloops do corrupt data if you're without journaling
Always remember to clear your UV/OC settings before flashing another kernel!
Take note that the ability to OC/UV depend on your phone. Some SGS can UV better or OC better and some might not.
On how to UV:
1. You can UV more on the lower frequencies than the higher frequencies.
2. Do a UV for
100MHz with (950-150=800) - Take note that 950 is the base value for the voltage. Some kernels might have changed this value to 925 or 900. This is why clearing your OC/UV settings is important as the OC/UV settings will only load the voltage difference, which in this case -150. If the base voltage is 900 and you do a -150 for it, you'll end up with 750 which might cause bootloops.
3. Limit the max frequency to 100MHz. WARNING: Doing this will significantly slow down your system to a crawl, but it is still running. This is done only to test the stability of your system. You can skip this if you want, but you would need to find a way to stress test your CPU at the 100MHz value (and other values as well by limiting the max frequency). Failing in testing this will result in deadsleeping (as your phone is in 100MHz when you sleep and if you undervolt too much, you deadsleep)
3. Test with RockPlayer (or MX Video Player) and play an RMVB file using software decoding for 10mins. If your settings is unstable, Android will freeze up and reboot. (this is just an example, but I find that this way stresses the CPU to the max. I fail to find another way of stressing it as even playing NFS is stable on some voltages but fails when I play rockplayer. Hence rockplayer is the best way so far)
4. After doing this, remove the limit and move on with the next few frequencies.
The rest of the voltages, just rinse and repeat.
200MHz with (950-100 = 850)
400MHz with (1050-75 = 975)
800MHz with (1200-25= 1175)
1000MHz with (no change)
You can experiment with lesser values than these if you get freezes/bootloops as this is by no means a one size fits all value. Some might think this UV is overly aggressive or some might think that this UV value is too underwhelming.
Mine if you're interested:
Code:
100MHz = -200 (950 base)
200MHz = -150 (950 base)
400MHz = -125 (1050 base)
800MHz = -75 (1200 base)
1000MHz = -50 (1275 base)
As for OCing, you would do the same to test the stability. Just that you will be enabling a higher clock for your L0 frequency (L0 is the highest frequency). Some kernels might add more frequency states i.e. from the 5 states above to 6. You can try using Tegrak OC app too. It all depends on your own experimentation.
Memory Leaks
If you found out that your Android is laggy after sometime and a reboot will make it faster, then you're experiencing memory leaks. "free" is a command to show your currently free memory. It will not necessarily be the same value as your phone's free memory (as it takes into account swaps and buffers)
1. Go to terminal emulator (or download the script at Post #3)
Code:
su <ENTER>
free <ENTER>
This will show your buffers and free memory.
My example:
Code:
total used free shared buffers
Mem: 348548 340280 8268 0 1320
Swap: 163836 47292 116544
Total: 512384 387572 124812
Then do this:
Code:
sync <ENTER>
echo 3 > /proc/sys/vm/drop_caches <ENTER>
Type:
Code:
free<ENTER>
And you'll realize that the buffers will reduce and free memory will increase, like this example:
Code:
total used free shared buffers
Mem: 348548 305212 43336 0 88
Swap: 163836 46804 117032
Total: 512384 352016 160368
That means it's done.
Click to expand...
Click to collapse
If this solves the laggginess problem, it's due to vfs_cache_pressure being too low and dirty_ratio being too high. However, in most cases, you don't have to do this as Linux will manage to clear the RAM in a timely manner as long as there are no apps that constantly hold on to the memory (not releasing it). Hence, only do this when necessary (lagginess and such).
With that, I've updated the system_tweak yet again, with this knowledge by making the VM settings more aggressive, which will trigger the memory leak faster. I made this so, as there's a workaround to clear the caches when it gets full.
Having a low vfs_cache_pressure and a high dirty_ratio will save battery and make your device perform faster at the cost of higher RAM usage.
You can actually automate it by using Script Manager by making a script, pasting the instructions and making a widget out of it. To learn more, read the android market description or the in-help guide in the app.
Some commonly asked questions about drop_caches that were answered by me from flolep:
http://forum.xda-developers.com/showpost.php?p=17727859&postcount=3428
http://forum.xda-developers.com/showpost.php?p=17731938&postcount=3446
http://forum.xda-developers.com/showpost.php?p=17736421&postcount=3450
Checking for Battery Drain/ Saving battery
Starting from Gingerbread, you can't really look for Partial wakelocks anymore to determine what is draining your battery at night. BetterBatteryStats is a way to check for that. It also can provide the process that drains your battery most of the time.
A high partial wakelock usually says that something is waking up your phone at night. With that, checking partial wakelock, you can see if these are the culprit:
-Network Location
-Location Manager Service
If so, disable Lattitude or any location check-in app that you're using. It's checking you in every few minutes that drains the battery.
Disabling Wifi/3G/HSDPA saves battery too. I find that Wifi/Edge drains the least amount of battery when idling. To switch to EDGE as opposed to HSDPA/3G.
Go to:
Code:
Settings > Wireless > Mobile Networks > Network Mode > GSM Only
Disabling "Use Wireless Networks" in location and security would save a little bit of battery too I guess. It's in:
Code:
Settings > Locations and Security > Use wireless networks
CSC
CSC is a folder that defines your APN settings and country/region specific configurations aside from Language/Time that is configured in build.prop(also for Samsung Apps).
Having to manually set your APN is annoying right?
Your product code being KOR by default is another annoying thing to deal with. How do I resolve this?
1. Get your CSC from your own country here: http://forum.xda-developers.com/showthread.php?t=948790
2. Extract from the zip file /system/csc/<folder> (where <folder> is your Country's CSC)
3. Use Root Explorer/File Expert to copy it to the phone's /system/csc/.
4. Use nitrality to change your product code. WARNING: This will wipe all your data.
Odexed vs Deodexed
I've been using Deodexed ROMs since I first flash my custom ROMs. One gripe I have is that I seem to have lost the stock smoothness/speed that I experience when I'm using a stock ROM. I found out that deodexing actually extracts the customization files back to the APK (using APK manager) and Odexed files are actually done to optimize the speed of those files itself.
The only reason ROM chefs are using deodexed files is that it is easier to theme. There is no need to decompile the odex files and make the changes as all the theme files are in the APK themselves.
Only other reason that I know of is the overscroll glow. Odexed files can't support it. However, that is a small price to pay for speed/smoothness that I am willing to sacrifice.
Busybox
Busybox is required to perform all of your superuser activities in your android phone. There are some problems associated with this when ROM developers decide to use a certain version of Busybox that are incompatible with the binaries that we use in our phones. When you found out that after changing your kernel/ROM:
- You still have superuser and Titanium Backup still works but,
- Root Explorer/File Expert can't copy files correctly to the /system after mounting rw
- Voltage Control/ Pimp My CPU/ Control Freak/ SetCPU cannot create the Svolt_scheduler file in /etc/init.d
You have a clashing busybox version issue. This can be remedied by:
- Installing the busybox installer from the market
- Installing busybox 1.17.x into /xbin
- Removing all other busybox binaries from your binary path. (This is optional if you found out that after installing busybox, everything works. Try it first before removing) To know your binary path, do an
Code:
echo $PATH
Nandroid Backup
Nandroid Backup is done in recovery (VolumeUp + Home + Power). In recovery, choose Backup And Restore. What it does is it backs up your:
- Boot
- System
- Data
- Cache
When you restore, you should preferably use Advanced restore and restore the /system and /data. All others can be built from scratch (except /boot). If you're converting from CM7 to Samsung Roms, it's best to start from scratch either ways. Restoring nandroid from any is considered dangerous and not supported by most cases. Best is to use Titanium Backup to backup as it can be restored both ways (only restore app though, restore data sometimes can lead to FCs)
Voodoo Color
Voodoo Color is also a point of contention among users. Some like it and some hate it with a passion. If your kernel does support it, here's a way to tweak it:
1. Tweak the color profiles. Can't see a difference, hence I would just pick Voodoo most of the time.
2. Tweak the gamma first to a comfortable value. I.e. drag the 3 sliders together to a comfortable gamma level. After that, try looking in the gradient (the gray slab below the slider) and try to find for neutral gray values. Adjust each slider until you find a neutral gray (i.e. left and right until you see that slab is truly gray)
3. Tweak the RGB multiplier until you have a comfortable level (3 sliders together). Then tweak it the same by referring to the gradient until you're comfortable.
4. Switch off your display for a while and look at your surroundings to reset your eyes. Then turn on your screen again and see if its too green/yellow/blue etc. Adjust the gamma/RGB multiplier until you're satisfied.
This might take a few rounds of testing, but in the end you'll be truly satisfied with it
i9000 Specific
i9000 Kernels - In Depth
You will need to have a stock odexed (why odexed? read a few passages below)ROM with root. You can easily do this by flashing stock XXJVS 2.3.5 and then flashing a custom kernel through Odin like:
- Dark Core - Uses Voodoo initramfs
- CF-root - Uses CF-root initramfs
- Semaphore - Uses CF-root initramfs
- Midnight - Uses Speedmod initramfs
- Galaxian - Uses CF-root initramfs
- Voodoo - Uses Voodoo initramfs
You can flash the custom kernel through Odin by placing the tar file into the PDA section and pressing Start. At this point, do not convert your partitions to ext4 (lagfix) unless you're using a Voodoo based initramfs as Voodoo based initramfs will convert your partitions to ext4 automatically at first boot.
After flashing a custom kernel through Odin, you will gain root. From there, you can choose to use any other custom kernels that use CWM to install or stick with the custom kernel that you've flashed through Odin like:
- TalonDev - Uses Voodoo initramfs
- TalonSH - Uses Voodoo initramfs
There are other kernels as well, but since I did not stress test them, I will not include them here. This thread lists the full repertoire of custom kernels that you can choose from:
http://forum.xda-developers.com/showthread.php?t=1196704
On which custom kernel to pick, you're advised to look at the individual threads original post as well as the last 5 pages of the thread to know about its stability and features. I pick TalonDev myself as it has compache as well as the latest upstream (kernel updates from the Linux OS as well as the official Android Open Source Project/AOSP and optimizations) patches.
At this point, you should decide if you would want to convert to ext4 (lagfix) or not. Your phone by default will reside in an RFS system. The RFS at this point in time is pretty stable and its performance can easily match ext4. Too bad Quadrant scores are bad for RFS, but who cares about Quadrant anyways. I myself choose to use ext4 as the TalonDev kernel has a lot of ext4 upstream patches that optimizes the usage of ext4 on Android.
If you're using Voodoo initramfs, you'll be converted to ext4 automatically.
If you're using CF-root initramfs, you will require the CF-root ext4 app to convert that can be found here:
http://forum.xda-developers.com/showpost.php?p=12651371&postcount=7
Note that on some kernels that use CF-root initramfs, the ext4 app will warn you that you're not on CF-root type kernels. Ignore this warning. You'll be able to convert to ext4 anyways unless you're on Galaxian. Certain Galaxian versions (since the kernels are not versioned, I can't tell which versions are not working) will bar you from converting to ext4 using the ext4 app. If that is the case, just flash CF-root, convert to ext4 and then flash back to Galaxian.
Also not that CF-root based initramfs kernels will remove your bootsounds on first boot. Don't be alarmed by this.
In terms of which lagfix is better (Voodoo vs CF-root lagfix), I can't tell at this point in time. Both are equally good. Since TalonDev uses the Voodoo initramfs, I am inclined to use the same when I am using the same kernel. That should be a good yardstick to follow.
BIGMEM/ Non-BIGMEM:
Some kernel developers released BIGMEM versions of their kernel:
-TalonDev BIGMEM
-TalonSH BIGMEM
-Semaphore bm version
The only difference a bigmem kernel can bring is more memory at the expense of 720p video recording. Playing a 720p video is still possible. Recording it is not on a bigmem kernel. Bigmem kernels normally have 13MB more than their non-bigmem counterparts. How this 13MB could affect you? It depends on the apps you use and how aggressive your LowMemoryKiller is.
XXJVT System apps
System apps can be frozen/removed to make your system faster/less battery draining.
In order to remove/freeze system apps, you would need Titanium Backup (Pro) or System Tuner.
The choice whether we want to remove or freeze the system apps should now be decided. Titanium Backup Pro and System Tuner uses a built in Android mechanism to freeze your system apps - PM disable. PM disable will actually disable the app from the system itself. It will not drain the battery or even launch itself. It is a safer way so to speak. Removing will physically delete the APK app from the system freeing up disk space. If you decide to remove, make sure to have a backup before proceeding. Even if you have a backup, restoring from Titanium Backup may sometime fail. Hence, do this only if you're sure you want to remove that certain app. Freezing an app will make it easier to defrost without any consequences.
Here are the apps that I disabled:
Code:
AngryGPS > Used to manually configure GPS. Not needed if GPS works OK.
BluetoothTest
Buddies Now
lcdtest
screencapture > Screen capture app
Daily Briefing
Days
EncryptApp
Factory Test
Gallery -> I use QuickPic as a replacement. It's faster than Gallery.
Google Partner Setup
Google Search > Google search widget
Home screen tips
HTML Viewer
Market Feedback Agent
Market Updater > I froze this to avoid being updated to Market 3.0. It currently sucks now
Mobile tracker > Mobile tracker, only if you use it, then keep it
Mobile tracker settings > Mobile tracker, only if you use it, then keep it
Perso
PhoneSetupWizard > Required if you're first booting/installing the ROM, not needed afterwards
PopupuiReceiver
Press Reader
Print via Bluetooth
RoseEuKor
Samsung Account
Samsung Keypad -> I use Swype beta instead
Self Test Mode
Service mode
SimDetachNotifier > Will notify you if you detached your sim card. Seems pointless
SNS > Only necessary to sync your contacts if you're using Social hub to do so or syncing calendar from Facebook
SNSAccount > Same as above
Social Hub
Software Update
Synchronise
TwLauncher -> Using Go Launcher Ex instead
wipeoutreceiver > Wipe if phone is stolen. Not needed if you don't use the Samsung service
WlanTest
wssyncmlnps
There are others that you can remove as well. I'm hoping to gather feedback on the other APKs that can be removed and what will be affected by its removal. Please post if you have more information
Disabling Lagfix
Most ROMs would advice you to disable lagfix before flashing a new ROM. Although this is not necessary in most cases (as all Gingerbread kernels support ext4 from the get-go) moving from one kernel to another might need it (to optimize the initramfs it is used on). Hence if you're swapping from one kernel (that has a different initramfs) to another. It is adviseable to undo the lagfix.
CF's lagfix can be undone by using the ext4 app.
Voodoo lagfix can be undone by using the Voodoo Control App.
Speedmod lagfix can be undone by using it's recovery.
Odexed ROM
You might say, hey if I'm using stock, I'll be missing extended power menu, battery percentage and all other theme mods that are not in the stock ROM. Fear not, you can get all these back including Gtalk2, CRT screen off etc here:
$omator's stock+
Gtalk2
There are odexed themes too, in which the developers would decompile the odex files into APKs, make the changes then compile the APKs into odex files again. It is more tedious than deodexed themes but odexing generally makes the phone smoother
You can find the themes here:
http://forum.xda-developers.com/forumdisplay.php?f=666
WIFI Issue on JVR/JVS/JVT
You might be facing some wifi connectivity issues on JVR/JVS/JVT ROMs i.e. it disconnects every few seconds.
This is due to some changes in the ROM that doesn't permit a "Forever" lease time from your modem. Change your lease time to an hour (or two) or if you don't have that option, remove your address reservation option from your modem (Yes, it's a modem only tweak, nothing you can do on your phone)
Memory Freak
Memory Freak is an app in TalonDev that tweaks the ZRAM/Swap and LMK settings. There's a golden rule to the ZRAM/Swap that is:
Swapping to and from the ZRAM will be slower if the amount of ZRAM is more than 50% of the total usable memory, . Hence, I set mine to 160MB (from the 340 total usable RAM). Swappiness in most Linux machines is 60. This means, the system will be inclined to swap in/out more than just using the RAM. I set mine to 50 as a personal preference so that there would be 50% chance that the system will use swap or RAM.
HiddenApp is the amount of free memory to be when LMK starts looking for hiddenapps to kill. I set mine to 52 for my multitasking preference. Experiment with it to see how much multitasking vs smoothness you're looking for. My preference will change in time. Check my signature for the most updated ones.
WIP:
This is obviously a work in progress article that will undergo changes as the Android scene improves. I will spend time to make edits and additions to the post whenever I see fit. Sometimes I will post changelogs at the end of the thread, sometimes I won't if I only make minor edits. Just be sure to check back often to see any new tips offered
Credits:
I claim no credit on these findings except for the ones that I've researched on my own. However, all of it is not of original work since I form my own opinions after reading a lot. I also don't claim that the settings I posted are the most optimal there is. It might not even work well for most of you guys. The key here is tweaking it to your own perfection as there is no setting that will cater to everyone's needs. Hence the real people who deserve credits are:
* All the devs' kernel/apps that I posted here
* XDA forum
* Google
Attention!
If you're looking for scripts, here it is:
[CWM][SCRIPTS][TWEAKS] Thunderbolt!
Script Reviews are here:
Script Reviews
GUIDE UPDATES
UPDATE 1/10/12
* Edited some sections with some new knowledge that I have. A few places, can't name them all Check them out and see if you can spot them.
UPDATE 10/19/11
* Moved around some guides and grouped them together
* Updated some guides to make them more Android centric (as opposed to i9000 centric)
UPDATE 10/18/2011 - Added an indepth article about LMK/OOM. CTRL-F for LMK.
UPDATE 10/12/2011
* Added some comments on the apps removed/frozen so that you can make an informed choice of why the apps can be removed/frozen.
* Added my analysis of most schedulers that I know of and why they are good/bad.
* Moved the scripts to ThunderBolt!: LINK
* Added a guide on the wifi issue for JVR/JVS/JVT
UPDATE 10/1/2011 - Moved the script reviews to this post LINK
UPDATE 9/23/2011:
* Removed the JournalingOn.zip and Acid Tweaksv6 - Removed Useless Stuff.zip because people might use it for devices other than the i9000. This is because in other devices such as SGS4G, the /dev/block/stl10 is /data while in i9000 it's /dbdata. The JournalingOn.zip will not enable journaling on /dbdata without some editing. Hence, I removed it as I don't have a time to put up a warning or notice, and didn't have time to edit the script inside the zip file.
* Readded an edited JournalingOn.zip and readded the Acid Tweaksv6 - Removed Useless Stuff.zip (did not change) to the first post. Only for i9000 devices!!
* Added another way to check if you're journaled or unjournaled. Check the guide below.
* Added some more explanation on common scripts I found.
* Moved the guides around due to lack of space. I added some minor changes to most of the guides. See if you can detect them

Helpful!
pikachu01 said:
Yes it is safe to remove for a deodexed ROM too
My point of stating odexed is that my tweaks can be used from the stock odexed ROM itself
Click to expand...
Click to collapse
oh ok, now I understand, thanks for this thread, very helpful indeed .

Awesome post thanks!
Not only for the tips but for teaching me a lot too!
Sent From My Android Shizzle!

thx dude!! awesomely useful!!

Great information thanks
Can you please include GPS tweaks as well?

awesomeandroid said:
oh ok, now I understand, thanks for this thread, very helpful indeed .
Click to expand...
Click to collapse
Thank you for reading it.
SkinBobUk said:
Awesome post thanks!
Not only for the tips but for teaching me a lot too!
Sent From My Android Shizzle!
Click to expand...
Click to collapse
It was my hope that it will give knowledge so that people could pass it on to more people
midikarma said:
thx dude!! awesomely useful!!
Click to expand...
Click to collapse
Thank you
ajazz said:
Great information thanks
Can you please include GPS tweaks as well?
Click to expand...
Click to collapse
Thank you for reading it What kind of GPS tweaks? There are a few notable ones. The most useful ones are disabling AGPS as well as updating the gps.conf. Do you mean that?

Oh man... Thx for your work... This thread is very useful.
I take my hat off.
Sent from nobody knows where

Wonderful job, pikachu01! A new user will need weeks, maybe months to gather all the bits of info you put here, served on a silver platter! Thank you veeeery much.
Mods, this should be stickied!

demonstone said:
Oh man... Thx for your work... This thread is very useful.
I take my hat off.
Sent from nobody knows where
Click to expand...
Click to collapse
Thank you
ZioGTS said:
Wonderful job, pikachu01! A new user will need weeks, maybe months to gather all the bits of info you put here, served on a silver platter! Thank you veeeery much.
Mods, this should be stickied!
Click to expand...
Click to collapse
Thank you Zio I forgot to add a few more posts to reserve. I guess I will add links if I do have any other things to add

Indeed lots of good info here for people just starting out, and some for people like me who've been around the block once or twice too!
I figured out how to do the CSC change myself, I just put the BMC folder from stock ROM into /system/csc and used one off the CSC selector apps from the market. Is this much different from the instructions here?
Since this has brought up the topic of freezing apps I will ask a question here if I may: Is there a way to keep apps from starting services, without getting rid of them? For example I use Skype and Facebook but I don't want their services running all of the time sucking up memory. Also I notice now that I game I installed recently (E Warriors) is running a service! WTF this is out of control. Any ideas?

haloimplant said:
Indeed lots of good info here for people just starting out, and some for people like me who've been around the block once or twice too!
I figured out how to do the CSC change myself, I just put the BMC folder from stock ROM into /system/csc and used one off the CSC selector apps from the market. Is this much different from the instructions here?
Since this has brought up the topic of freezing apps I will ask a question here if I may: Is there a way to keep apps from starting services, without getting rid of them? For example I use Skype and Facebook but I don't want their services running all of the time sucking up memory. Also I notice now that I game I installed recently (E Warriors) is running a service! WTF this is out of control. Any ideas?
Click to expand...
Click to collapse
Yes, the CSC instruction does the same thing. I'm just a bit thorough sometimes
You could use System Tuner or Titanium Backup Pro to freeze the app and then unfreeze it when you want to use it. Freezing is actually just doing a PM disable. PM disable basically makes Android think that the app is gone when it's actually still there. Unfreezing an app is basically just 1 click, hence its hassle free.

ZioGTS said:
Wonderful job, pikachu01!
Mods, this should be stickied!
Click to expand...
Click to collapse
Agreed +1
Excellent & informative

Awsome post pika.. Great work.. thx

Very nice tutorial. Should be pinned

Sticky please (with sgs chlorine).
Great work, much appreciated.
Sent from my Galaxy S using XDA Premium App

pikachu01 said:
Thank you for reading it.
It was my hope that it will give knowledge so that people could pass it on to more people
Thank you
Thank you for reading it What kind of GPS tweaks? There are a few notable ones. The most useful ones are disabling AGPS as well as updating the gps.conf. Do you mean that?
Click to expand...
Click to collapse
I have tried lot of Roms and none gave me satisfactory GPS performance except InnOvaTioN v2 by bezke,this Rom gave me almost instantaneous gps lock , when under partial cover it took a minute or so !
Then i moved on to v3 and was back to square one!
unfortunately v2 is no longer available for download.
I have tried Faster Fix, Gps Aids, tried changing setting through sgs tools but no go.
even tried different modems.

ajazz said:
I have tried lot of Roms and none gave me satisfactory GPS performance except InnOvaTioN v2 by bezke,this Rom gave me almost instantaneous gps lock , when under partial cover it took a minute or so !
Then i moved on to v3 and was back to square one!
unfortunately v2 is no longer available for download.
I have tried Faster Fix, Gps Aids, tried changing setting through sgs tools but no go.
even tried different modems.
Click to expand...
Click to collapse
well, then open a thread on general, Q&A, etc.
and let someone upload it
hopefully there are still copys of it out there
so there's a way to analyze and understand what was done to get those great results
@pikachu01:
great work on collecting all of this information & putting it in a central place !
*subscribes*
+1 for sticky

Very nice guide. It'll be very helpful for begginers. +1 for the idea to stick it

[PnP&Thermals tweak] Custom profiles for battery saving and/or better performance-v24

Addon was originally only available on Venom HUB but i decided to release it for everyone to use.Here is copy paste of description and changelogs from the HUB.I will update thread as i update it on HUB.
Also big thanks to @hamdir for testing my performance profile on various games, he will also post later hes review, pictures and comparisons to stock.
This addon is designed to save some extra battery, and reduce heat.Magic is done in 2 files:
1:Thermal-engine is tweaked in order to provide much better sustained performance and cooler phone, without big impact on performance.
2np file is another key component, its HTCs CPU/GPU/EMMC/MODEM and many more control engine.Here many tweaks where done, but gonna quickly list some of the important ones:
-Per app control, automatically suspends 2 BIG cores, and runs on 2 low power ones, it also limits the GPU speed to lowest.This will do only for some most commonly used apps, like Sense Prism, Nova launcher, Apex, other HTC apps, various chat programs(hangouts, facebook, messanger, whatsap etc), YouTube and some more.. as those apps dont require a lot power.
-Screen off is set to 2 low power cores for nice standby times
-Power saver is tweaked to actually save some power and not just lower screen brightness
-Extreme powersaver is also tweaked down to save even more power
-Input boost frequencies are also lowered (CPU ramps up moment you touch screen)
-And alot of other minor tweakups..
Also its recommended not to change anything CPU/GPU related in any other apps, like EX and just let this files do the job for you.
If for some reason you dont like this mod or have any problems with it, installer includes revert to stock option
Click to expand...
Click to collapse
Read more info in changelogs below.
List of battery optimised apps (feel free to post your suggestions):
Code:
com.ninefolders.hd3
com.applisto.appcloner
com.livae.apphunt.app
com.fillobotto.mp3tagger
org.polaric.cluttr
com.rgiskard.fairnote
com.glextor.appmanager.free
com.catchingnow.undo
kik.android
de.onyxbits.listmyapps
org.zloy.android.downloader
com.slaughter.look.of.disapproval
gaurav.lookup
cn.wq.myandroidtoolspro
com.embermitre.pixolor.app
de.toastcode.screener
de.munichsdorfer.screenittrial
com.glitch.stitchandshare
com.stumbleupon.android.app
org.de_studio.recentappswitcher.pro
com.happening.studios.swipeforfacebookfree
com.laurencedawson.reddit_sync
com.fifthelement.trimmer
com.camel.corp.universalcopy
com.google.android.apps.inbox
com.riversoft.android.mysword
com.taxis99
com.tbig.playerpro
com.tomtom.gplay.navapp
com.xda.labs.play
com.google.android.apps.translate
com.safeincloud
com.mobisystems.msdict.embedded.wireless.collins.p ortuguese.full
com.mobisystems.msdict.embedded.wireless.oxford.es sentialportuguese
com.accuweather.paid.android
com.mobilesrepublic.appy
com.pandora.android
com.slingmedia.slingPlayer
com.bumble.app
com.tinder
com.klinker.android.twitter_l
com.nam.fbwrapper.pro
com.timehop
jp.naver.line.android
com.linkbubble.playstore
kr.co.vcnc.android.couple
com.joshua.jptt
com.noinnion.android.greader.reader
com.netbiscuits.kicker
com.redictandcgdstudios.projectslenderonline
com.teotlstudios.slenderrisingfree
com.dvloper.slendermanriseagainfree
com.RexetStudio.SlenderTheRoad
air.com.sticksports.sticktennis
com.sticksports.sticktennistour
com.bauermedia.tvmovie
de.wetteronline.wetterapppro
com.redictstudios.projectslender
se.feomedia.quizkampen.de.premium
com.quoord.tapatalkHD
com.droid27.transparentclockweather
com.speedsoftware.rootexplorer
pl.solidexplorer2
com.appseleration.android.selfcare
com.google.android.apps.chromecast.app
rpkandrodev.yaata
com.andrewshu.android.reddit
com.xodo.pdf.reader
com.microsoft.office.word
com.microsoft.office.excel
com.kmobile.cb
com.nianticlabs.pokemongo
com.google.android.apps.maps
com.htc.laputa
com.papago
com.mapbar.android.mapbarmap
com.autonavi.cmccmap
com.baidu.BaiduMap
com.pdager
com.kingwaytek.naviking
com.htc.lockscreen
com.htc.fingerprint
com.xda.labs
org.mozilla.firefox
org.mozilla.firefox_beta
com.emoji.keyboard.touchpal.oem
com.nitrodesk.honey.nitroid
com.android.calculator2
com.estrongs.android.pop
com.tbig.playerpro
org.telegram.messenger
com.instagram.android
org.wordpress.android
com.touchtype.swiftkey.beta
com.gsamlabs.bbm
com.htc.android.worldclock
com.quoord.tapatalkpro.activity
com.anddoes.launcher
com.google.android.gms
android.uid.systemui
com.android.systemui
com.chrome.beta
com.android.chrome
com.chrome.dev
com.teslacoilsw.launcher
com.spotify.music
com.quoord.tapatalkxdapre.activity
com.google.android.apps.plus
com.twitter.android
com.htc.AutoMotive
com.google.android.talk
com.viber.voip
com.ninegag.android.app
com.android.settings
com.devhd.feedly
com.htc.weather
com.google.android.phone
com.htc.sense.mms
com.htc.contacts
com.htc.htcdialer
com.htc.music
com.maxmpz.audioplayer
com.google.android.apps.photos
com.htc.launcher
com.htc.sense.news
com.whatsapp
com.facebook.katana
com.facebook.orca
com.m0narx.hub
com.ice.tweaks
com.m0narx.tweaks
com.google.android.youtube
com.google.android.videos
Compatibility:
All 1,8x, 1.9x and 2.x based roms bases and kernels(even stock roms/kernel's).
Not compatible with 1.5 or below bases (will cause random crashes), use Version v8 for older 1.5x and 1.2x bases.
Download:
Version v24
Download link flashable ZIP - AFH
Older versions:
Version v23
Download link flashable ZIP - AFH
Version v22
Download link flashable ZIP - AFH
Download:
Version v21
Download link flashable ZIP - AFH
Version v19
Download link flashable ZIP - AFH
Version v18
Download link flashable ZIP - AFH
Version v17
Download link flashable ZIP - AFH
Version v16
Download link flashable ZIP - AFH
Version v15
Download link flashable ZIP - AFH
Version v14
Download link flashable ZIP - AFH
Version v13
Download link flashable ZIP - AFH
Version v12
Download link flashable ZIP - AFH
Version v11
Download link flashable ZIP - AFH
Version v10
Download link flashable ZIP - AFH
Version v9 TEST
Download link flashable ZIP - AFH
Version v8
Download link flashable ZIP - AFH
Version v8 for older 1.5x and 1.2x bases
Download link flashable ZIP - AFH
Changelog:
Code:
24.04.2017
v24:Fixed remove 50 -> 60 fps boost on touch on performance profile(60fps locked now)
- MaxPowerSaving profile optimizations to get even more battery life.
27.03.2017
v23:Added more user requested apps(30) for battery optimised profiles
- Attempt to smoothen Facebook app scrolling (App still lags while loading items on any phone)
- Increased touch input boost speed for MaxPowerSaving profile(smoother scrolling)
16.01.2017
v22:Viper Magisk compatible
- Merged with 2.41 base changes
- Added a lot more apps for battery optimised profiles
- Added new MaxPowerSaving profile:
Limits CPU to 1.3/1.78GHz(LC/BC), GPU 510MHz
Launching apps bypasses above limit for fast app starting/switching
Still uses balanced mode per app profiles which saves even more power
- Cleaned installer from unnecessary files (smaller zip size)
9.12.2016
v21:Lowered input boost, touch boost, long duration touch boost, app launch and per app frequencies for even more battery savings(N is still very smooth)
-Cleaning of code and some other fine tuning
24.11.2016
v20:Merged with Android 7.0.0 changes
-Also backwards compatible with 1.5x + bases
26.09.2016
v19:Fixed CPU doesnt drop to lowest speed for some users/kernels
- Merged v18 balanced changes into performance profile
22.09.2016
v18:(Balanced changes only)
- Adjusted CPU scheduler load distributions and frequencies in order to fix some stutters,
but also to save power while phone is idle with screen ON (drops to lower frequencies faster)
- Fixed weird HTC bug where task migration gets stuck in loop and cause phone to heat up for no reason
- (thermal file)Make it a bit cooler on higher loads
- Minor fine tuning here and there..
29.08.2016
v17:Prevent cores going offline if running Android auto (fixes lag on screen off)
- (Balanced)Tweaked 15+ various governor and boost settings for even more power savings
- (Balanced)Added more appps for CPU limiting profiles
- Allow 4 threads for oat proces if PlayStore in focus(faster app install)
23.08.2016
v16:Merged latest HTCs changes realted to PokemonGo thermals
- Removed 50 -> 60 fps boost on touch on performance profile(60fps locked now)
- Forced 60 fps for YouTube and Google videos on balanced profile
- Tweaked thermal file on balanced profile for better performance
07.08.2016
v15:Balanced and Performance profile update
- Fine tuned values
- Big cores go offline during screen off for Performance profile
- Tweaked low memory killer values on both profiles,
prevents often app reloading, which is waste of time and battery.
04.08.2016
v14:Balanced and Performance profile update
- Implemented dynamic swappiness
- Default swappiness reduced from 60 to 30 (less writes to nand)
- During app launch or touching screen event swappiness is reduced to 0
- During screen off swappiness is set to default 60 so it can do its job when we are not using phone
- Increased dirty_ratio to reduce even more writing to nand
- Overall goal is to reduce I/O on NAND while using phone and in that way improve performance,
but also improve battery by better utilizing the 4gb RAM that this device has.
- Added more apps for CPU limiting profiles(balanced only)
v13:
-Merged with changes from 1.9x base
(Mostly fine tuning battery saving for various video chat programs)
v12:Balanced profile changes
- Added more commonly used apps for lower power CPU profiles
- More fine tuning
v11:
- Fine tuned balanced profile to prefer a bit more battery life
- Cleaned up aroma installer (wont create unnecessary Venom folders for non-Venom users)
v10:Balanced profile rebuild
- Merged and fine tuned/adjusted thermal configuration from performance profile
- Should improve responsiveness and fix stuttering on some apps that happend before
- changed around 100+ lines of code, lazy to write full changelog :p
v9:TEST balanced profile update
- Big cores will now go fully offline during screen off and while in Extreme powersaver
- Lowered screen refresh rate while in Extreme powersaver(even more saving)
- Max GPU speed limited to 214MHZ while in Extreme powersaver
- Max GPU speed limited to 510MHZ while in powersaver
- Reduced app launch boost MIN frequencies speeds to 1.3gz for all cores.
v8: complete rebuild of performance profile
- Added extra 560mhz frequency step between 630 and 510 for GPU throttling
- Added 5 additional throttling steps for each CPU cluster per temperature
- Prevent big cores dropping to 1.3ghz too soon which drops FPS in games.
- Prevent killing one big CPU core too soon, instead 2 will run at half migration performance.
- Everything fine tuned and balanced, 10+ FPS boost in most games compared to stock
v7
- 1.8x base compatibility update
v6
-Removed battery saving profile as balanced does such good job, both smoothness and performance! :)
v5
-Many changes to balanced profile
-Lowered app launch Max CPU speed locking to more reasonable levels(Still ramps up to max if load demands)
-Reduced input boost duration a bit
-Governor will now drop CPU to lower speeds faster
-Added more apps to lower CPU speed profiles.
v4
-Aroma installer fixes
-BatterySaving profile fine tuning
v3:
-2 new more options
*MaxPerfomance
*BatterySaving
-Tweaked is now called Balanced
v2:
-fixed YouTube 2k+ videos lag
This is example of battery life i get with Balanced profile
{
"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"
}
XDA:DevDB Information
PnP&Thermals tweak, Tool/Utility for the HTC 10
Contributors
ivicask, hamdir
Version Information
Status: Stable
Current Stable Version: v24
Stable Release Date: 2016-06-23
Current Beta Version: v9
Created 2016-07-06
Last Updated 2017-04-24

Performance Profile
I've worked with @ivicask on optimizing gaming performance for the 1.80 base via the performance profile for this mod, in this post i will explain the gaming problem on stock HTC 10 and how this mod/performance profile solves it
by default HTC aggressively cripples the Snapdragon 820, not for the sake of thermals but for the sake of extending battery life, what happens is the following:
Stock CPU behavior on HTC ten (up to 1.80 base):
Starting with 33c battery temp CPU tasks will gradually migrate out of the big cluster, around 38c one of the two big Kryo cores (which enjoy higher clocks and bigger hardware cache) will be completely disabled, HTC smartly hides it in task migration rather than physically shutting down a big core
This means in CPU intensives games like Dead Effect 2 you will notice a sharp drop in performance/smoothness once the fourth core is killed, the game will drop from the 60fps range to 30fps, this behavior is noticeable in many games, if you are on complete stock you can only game at the full s820 speed if you are starting from a cool idle battery temp like 30c but then in about 5 minutes things will go downhill, considering that the HTC 10 idle state in average use is around 35c anyway you can see how most people probably start gaming on the 10 within the crippled state
Previously the only way to fix was to flash EX kernel with CPU migration hacked and already set by default to 60% limit, meaning EX kernel will refuse to let HTC 10 migrate tasks out of the fourth core under 40%, this is a good solution but you are forced to use EX kernel and not the stock kernel plus wait for the kernel source so that EX is updated whenever an OTA is rolled out, this mod will allow you to fix gaming on HTC 10 without touching the kernel plus it's thermally safe as its not a hack and will still gradually slow down the 10 to cool down, but it does so in a sane way
The performance profile in this mod was thoughtfully optimized by profiling the CPU usage in Dead Effect 2 (currently one of the heaviest games on the playstore) from 30c up to 45c, giving you enough time to actually enjoy this game at its full speed up to 30 minutes
The following tests will show you how the HTC 10 behaves in gaming when warm vs the performance profile, profiled using @ivicask tools and game benched in short sessions, the exact same level played from the same starting point to the same end at the same length of time, this level called "return to space gardens" is one of the heaviest sections in Dead Effect 2, at the end of this test you can see how performance drops to the ground because it meets a very dense and tough section in the game.
Stock kernel / PNP / thermals, Dead Effect 2 at 39c
The fourth big core is completely killed, GPU goes to 510mhz, small cluster drops to 1.3ghz, big cluster drops to 1.5ghz
As you can see on pure stock 1.80 base by 39c the games loses one of the big s820 cores and performance drops from 45fps range in this level to 30fps (which happens way too fast) also as seen in the yellow graph how performance stability is terrible, after 40c it will get even worse
here are the results from the same level using the performance profile of this mod
Performance Profile, Dead Effect 2 at 34c to 38c
full tasks are still running on all cores, GPU at 624mhz, small cluster still at 1.5ghz, big cluster drops to 1.5ghz
Performance Profile, Dead Effect 2 at 39c to 41c
both big cores drops to 80% task migration, GPU drops to 560mhz, small cluster still at 1.5ghz, big cluster still at 1.5ghz
Performance Profile, Dead Effect 2 at 42c to 43c
one big core sticks to 80% task migration the other big core drops further to 60%, GPU drops to 510mhz, small cluster still at 1.5ghz, big cluster still at 1.5ghz
Once the device gets warmer after 43c CPU migration will drop to 60% on both big cores with further reduction in GPU speed etc, but at this stage the HTC 10 will no longer heat up as fast and as you can see up to this point it was maintaining almost the same performance in this game; while keeping fairly high GPU clocks too; this is a much more subtle well thought performance degradation than HTC's stock blind brute crippling of the s820 which happens way too fast on low temps
This profile is so good actually HTC should probably copy it and imitate how it deals with default CPU migration, otherwise why are we buying an s820?

ivicask said:
Addon was originally only available on Venom HUB but i decided to release it for everyone to use.Here is copy paste of description and changelogs from the HUB.I will update thread as i update it on HUB.
Also big thanks to @hamdir for testing my performance profile on various games, he will also post later hes review, pictures and comparisons to stock.
Click to expand...
Click to collapse
@ivicask
does it work differently from butterfly v11?
or say does it conflict with butterflyv11 if you have already loaded that profile and flash this zip?
thanks for another tweak made possible for Perfume devices

SacredDeviL666 said:
does it work differently from butterfly v11?
Click to expand...
Click to collapse
Completely different, it uses HTCs native engines to control everything, u can basically flash this on stock un-rooted phone
And doesn't require custom kernel, it should work immediately as new bases come out etc..

ivicask said:
Completely different, it uses HTCs native engines to control everything, u can basically flash this on stock un-rooted phone
And doesn't require custom kernel, it should work immediately as new bases come out etc..
Click to expand...
Click to collapse
aah okay cool...does it conflict if i have already enabled butterflyv11 which disables pnq or its safe to flash while using that script

SacredDeviL666 said:
aah okay cool...does it conflict if i have already enabled butterflyv11 which disables pnq or its safe to flash while using that script
Click to expand...
Click to collapse
Half of this mod runs in PnP, if you disable it, your making this mod almost pointless.
Also, as i stated, this mod runs best standalone, its best not to use any other mods, or apps which change anything CPU /GPU related.
You can still flash EX kernel for example, i just dont recommend messing with any CPU/GPU related settings in it.

ivicask said:
Half of this mod runs in PnP, if you disable it, your making this mod almost pointless.
Also, as i stated, this mod runs best standalone, its best not to use any other mods, or apps which change anything CPU /GPU related.
You can still flash EX kernel for example, i just dont recommend messing with any CPU/GPU related settings in it.
Click to expand...
Click to collapse
cool so this would conflict as butterflyv11 disables the pnp
would try this and see :highfive:

hey
great to see you released this for all on xda!
I have a question. since you wrote on the ex kernel thread that pnp config file is encrypted how come you can edit it?
or can you englighten me how i can just disable all Input and touch boosts from pnpmgr while keeping pnpmgr?
i think that would be the best for my script but i wasn´t able to do so.
i found no other way to stop the touchboost other than disabling pnpmgr completely.
maybe we can integrate my interactive values with your mod? if you are okay with this of course!
thanks

Freak07 said:
hey
great to see you released this for all on xda!
I have a question. since you wrote on the ex kernel thread that pnp config file is encrypted how come you can edit it?
or can you englighten me how i can just disable all Input and touch boosts from pnpmgr while keeping pnpmgr?
i think that would be the best for my script but i wasn´t able to do so.
i found no other way to stop the touchboost other than disabling pnpmgr completely.
maybe we can integrate my interactive values with your mod? if you are okay with this of course!
thanks
Click to expand...
Click to collapse
I cant give you much details on how i edit them, theres reason HTC encrypted them, if we spill it out, HTC would change encryption and everything very soon i suspect, so hope you understand why i wont share that part.
I can disable input boost for you, but im still not sure how your mod works along with PnP, as PnP constantly changes values dynamically, if you chmod values, than PnP constantly tries to change freqs and fails(may cause some problems).
What i can also do, is incorporate your changes directly into my mod, and make "ghostpeper" profile which would work directly in PnP, and people can choose and test which one works better for them and their daily usage.
EDIT:You could simple disable input boost by echoing 0(maybe chmod remove write permission after that so it cant change it) to
/sys/power/pnpmgr/touch_boost
/sys/power/pnpmgr/long_duration_touch_boost

ivicask said:
I cant give you much details on how i edit them, theres reason HTC encrypted them, if we spill it out, HTC would change encryption and everything very soon i suspect, so hope you understand why i wont share that part.
I can disable input boost for you, but im still not sure how your mod works along with PnP, as PnP constantly changes values dynamically, if you chmod values, than PnP constantly tries to change freqs and fails(may cause some problems).
What i can also do, is incorporate your changes directly into my mod, and make "ghostpeper" profile which would work directly in PnP, and people can choose and test which one works better for them and their daily usage.
EDIT:You could simple disable input boost by echoing 0(maybe chmod remove write permission after that so it cant change it) to
/sys/power/pnpmgr/touch_boost
/sys/power/pnpmgr/long_duration_touch_boost
Click to expand...
Click to collapse
yep i totally understand this. it would be however great if you could disable Input boost for me directly in the pnp binary.
i already tried to edit the files you mentioned in sys/power/pnpmgr. when i did this I got heavy lags. really heavy. i think something is conflicting there.
yeah the chmod trick worked before base 1.80. i would simply chmod the min freqs for big and Little Cluster and touchboost from pnpmgr disappeared magically. this trick is no longer working with the new base. that´s why i was forced to disable pnpmgr.
if you want to you can incorporate the Butterfly values for the interactive governor in your mod. I think Butterfly works far better on our 10, that´s why i just updated Butterfly for base 1.80.
does pnpmgr also edit the values for the interactive gov dynamically?
if you could make a pnpmgr config where touch/Input boost, Setting min/max freqs is disabled i´d be quite happy.
---------- Post added at 11:17 AM ---------- Previous post was at 11:10 AM ----------
SacredDeviL666 said:
cool so this would conflict as butterflyv11 disables the pnp
would try this and see :highfive:
Click to expand...
Click to collapse
you may also just edit my script and comment out with a # or delete the line "stop pnpmgr" then the pnpmgr conflicting part will at least be removed.

Noice. Thanks for sharing

Freak07 said:
yep i totally understand this. it would be however great if you could disable Input boost for me directly in the pnp binary.
i already tried to edit the files you mentioned in sys/power/pnpmgr. when i did this I got heavy lags. really heavy. i think something is conflicting there.
yeah the chmod trick worked before base 1.80. i would simply chmod the min freqs for big and Little Cluster and touchboost from pnpmgr disappeared magically. this trick is no longer working with the new base. that´s why i was forced to disable pnpmgr.
if you want to you can incorporate the Butterfly values for the interactive governor in your mod. I think Butterfly works far better on our 10, that´s why i just updated Butterfly for base 1.80.
does pnpmgr also edit the values for the interactive gov dynamically?
if you could make a pnpmgr config where touch/Input boost, Setting min/max freqs is disabled i´d be quite happy.
---------- Post added at 11:17 AM ---------- Previous post was at 11:10 AM ----------
you may also just edit my script and comment out with a # or delete the line "stop pnpmgr" then the pnpmgr conflicting part will at least be removed.
Click to expand...
Click to collapse
PnP controls everything u mentioned, all your butterfly/ghost scripts has, and about 10x times even more
I checked your script, you just echo to disable input boost, try chmod it after you disable it with denial permission so it cant be changed..
Should work, if not i can mode PnP for you, but above would be better solution for you..

Maybe others might ask too, sometimes I'm using it too for a systemless mod: do you plan to add it in as a systemless mod, if it is possible?

tbalden said:
Maybe others might ask too, sometimes I'm using it too for a systemless mod: do you plan to add it in as a systemless mod, if it is possible?
Click to expand...
Click to collapse
There is no need for that, it wont affect android pay or similar, why exactly you ask?

ivicask said:
There is no need for that, it wont affect android pay or similar, why exactly you ask?
Click to expand...
Click to collapse
well, just related to OTAs, but that might be unimportant as you can flash back to original files, or restore no-RW mounted system image backups.
Or am i lagging behind, it's working to have a RW mounted system and do OTA updates? I don't follow that part much, my bad

tbalden said:
well, just related to OTAs, but that might be unimportant as you can flash back to original files, or restore no-RW mounted system image backups.
Or am i lagging behind, it's working to have a RW mounted system and do OTA updates? I don't follow that part much, my bad
Click to expand...
Click to collapse
Its so much easier just to restore original image, i think wont do it systemless, as they are key system parts, dont want some weird things to happen..

ivicask said:
Its so much easier just to restore original image, i think wont do it systemless, as they are key system parts, dont want some weird things to happen..
Click to expand...
Click to collapse
OK.
I'm testing balanced option at the moment.
Also, i know I'm off topic, but in the end what's the recipe: what does and what doesn't affect androidPay. (I'm lagging behind again in this topic, just avoid modifying system partition in my kernel as it seemed to affect it at that time... as i don't use androidPay I didn't follow what exactly makes it unworking).

ivicask said:
PnP controls everything u mentioned, all your butterfly/ghost scripts has, and about 10x times even more
I checked your script, you just echo to disable input boost, try chmod it after you disable it with denial permission so it cant be changed..
Should work, if not i can mode PnP for you, but above would be better solution for you..
Click to expand...
Click to collapse
Thanks I will try this and come back at you

tbalden said:
OK.
I'm testing balanced option at the moment.
Also, i know I'm off topic, but in the end what's the recipe: what does and what doesn't affect androidPay. (I'm lagging behind again in this topic, just avoid modifying system partition in my kernel as it seemed to affect it at that time... as i don't use androidPay I didn't follow what exactly makes it unworking).
Click to expand...
Click to collapse
It checks alot of things, and its constantly updated, its simple must be done for security reasons..

Okay so I tried it with 444 permissions and it still lags. Should I try 000?
Would be great if you could make me a file with touchboost disabled and frequency changing disabled.

[MOD] Pixel 2 (XL) Unified Kernel(s) Tuning Script (v1.1a)

Introduction:
Hello everyone!
The idea to this 'project' did blossom after having an conversation with @pkgnex about the general idea of creating something else that follows what he started with his PK's Tuning Script but with a twist, mainly as a complement to his own thread that you can find here, but also with a completely different vision and focus on what the script itself should achieve (and deliver) for kind of results for myself and for all of you personally, of course, that wants to try it out and use it as a "daily driver".
Shortly explained.
This script is created with the goal of improving both the battery life and performance of our Pixel 2 (XL) devices, and after a whole range of configurations and various set-ups, I've come up with something that, in my eyes, is worth sharing with you so that you can try it out yourself and judge on your own, with constructive feedback on what can be improved or added in future releases - if desired. My philosophy is, and will always be, this:
If something can be improved or altered in a positive way so the average user can feel and see a difference, then go for it. Non stop.
Latest releases can be found here:
Major release
Minor release
Disclaimer:
This is presented as "what if". If this modification screws up or breaks anything for you, I am not the one to be held responsible. It's a free will to try out this kind of changes/modifications/addons/tweaks, just don't blame the inventors for eventual bad results and/or screw-ups.
Note: This script is not recommended to be modified or customized by the user.
Features:
Reduced battery consumption
Enabled, and configured, Boeffla generic kernel wakelock blocker
Disabled a lot of stuff at both kernel and system level (Improves battery life and performance)
Schedtune tweaks (Improves system responsivness)
Power efficiency enhancements
Wide IO block tuning (Reduces the possibility of hiccups, lags and overhead)
Possibly other miscellaneous things I've forgotten to write down here, both big and small.
Requirements/what you need for getting this script fully working:
An unlocked bootloader
Latest Magisk
Busybox for Android NDK Magisk Module by @osm0sis
Patience
Installation/How-To use & abuse:
1) Download the attached ZIP
2) Extract the script
3) Move 01tweaks to the following location;
/sbin/.core/img/.core/service.d and give it the following permissions (0755)
4) Reboot your phone, let Android boot to the launcher and let Magisk boot service do its crucial magic (takes about 60-65 seconds before the script is fully up and running behind the scenes)
5) Enjoy!
Credits:
@nathanchance for his contributions with his Flash Kernel
@franciscofranco for all the information on which kernel wakelocks that is safe to block
@Lord Boeffla for his awesome generic kernel wakelock blocker
@pkgnex for inspiring me walking into this partially unknown territory.
@flar2 for his excellent EXKM application and ElementalX Kernel
@osm0sis for his Magisk Busybox module
Everyone that I've forgotten to mention here
To-Do list:
Port this project to all of my additional devices
Include kernel specific scripts for every released P2(XL) custom kernel Done
- Even for stock kernel with SafetyNet patch by @iissmart Done
Optimize and properly tune things even further for best balance between battery life, system responsivness and performance
Contributors:
@xFirefly93
Created: 2018-09-18
Last updated: 2018-09-19

Changelog:
v1.2a (Minor release)
- Disabled OOM_Kill_Allocating_Task for all kernels.
- Cleaned up the scripts on a couple of useless lines (results in a smaller ZIP package)
- Reverted icmp_echo_ignore_all back to stock setting (Needs more private testing before I am including it again)
- Disabled IOWait Boost in a attempt to fix the idle frequency scaling issue that some have reported about
(Public release only, it's still included & enabled in the maintainer release)
v1.2 (Major release)
- Altered a few tweaks (that should improve battery life even further along the road)
- Added a couple of networks tweaks that should improve network performance & reduce battery drain when being on a wifi connection.
- Added updated scripts for Sultan, Kiriskura and stock kernel (with SafetyNet patch)
- Added two versions into the ZIP file (Public & Maintainer release, see information below)
- Updated version numbering and configuration descriptions
- Reverted schedtune tweaks in a attempt to fix the bouncing CPU frequency scaling issues that some have experienced
Descriptions (now and for further releases);
Public release: Public release contains scripts for each Pixel 2 (XL) kernel, and which is closer to Google's (and the respective developer's) own kernel (with my own carefully selected modifications, of course, applied and running on top of that).
Maintainer release: This is the scripts that I am using on my Pixel 2. Literally. Use this one of did not have any CPU frequency scaling issues on the previous versions, or just want to use exactly what I am using as a daily driver.
v1.1b (Minor release)
Note:
- This version only adding fixes to my script, mainly for Flash Kernel and ElementalX.
- Enabled performance daemon back online again (should fix reported issues with CPU frequency scaling on LITTLE cluster)
- Lowered schedtune values (less battery drain w/o any real performance regressions + should fix how often the CPU scales to max frequency)
- Added back my wide IO block tuning script for Elementalx (this was not the cause for the CPU bouncing issue)
- Enabled OOM_Kill_Allocating_Task for ElementalX (Disabled for Flashkernel)
v1.1a (First minor release)
Note:
- This release is including an enhanced release of v1.1, suitable for Flashkernel.
- Changed some parameters for a slight performance and UI smoothness boost
- Disabled OOM_Kill_Allocating_Task (Better to let the OOM killer select a random task to kill for freeing up memory when needed
- Disabled Backlight dimmer (If you want it back, tell me and I will upload a userspecific release with it enabled & configured)
- Some additional lag reducing enhancements
v1.1 (First major release)
- Initial releases for every released custom Pixel 2 kernel.
- Added a few additional settings for further battery life, as well as, performance improvements.
- Shortened a few lines which explains what the parameters changes does.
- Packed everything into a single ZIP file with specific names for each kernel tuning script.
- See attached ZIP in the OP
v1.0 (Initial testing & feedback release)
- Initial release.
- Note: This version is only tuned for Flash kernel. Next release/update will contain more scripts, specially tuned for each one of the released kernels across the whole Pixel 2 line-up.

Short note
If you have any kind of specific wishes or suggestions on changes and/or tweaks, either kernel specific or universal across the whole released kernel line-up for Pixel 2 (XL), that the pretty soon up-coming v1.1 should include (can be something that you have read about somewhere else or it is maybe something that I've missed) - send me a personal message asap and I'll take a deep look into it and see what's possible to do and achieve.
Or leave a comment here in the thread about it, if you prefer it that way.

Update!
v1.1 First major release
- Initial releases for every released custom Pixel 2 kernel.
- Added a few additional settings for further battery life, as well as, performance improvements.
- Shortened a few lines which explains what the parameters changes does.
- Packed everything into a single ZIP file with specific names for each kernel tuning script.
- See attached script below (and in the OP)
Enjoy!

Update!
v1.1a (Minor enhanced release)
Note:
- This release is including an enhanced release of v1.1, suitable for Flashkernel.
- Changed some parameters for a slight performance and UI smoothness boost
- Disabled OOM_Kill_Allocating_Task (Better to let the OOM killer select a random task to kill for freeing up memory when needed)
- Disabled Backlight dimmer (If you want it back, tell me and I will upload a userspecific release with it enabled & configured)
- Some additional lag reducing enhancements
Enjoy!

Update!
Note #1: I am moving all update posts and what not to my Pixel 2 XL thread instead. This one will just be used as an "notification updater" thread from now on, because jumping between and making sure both topics gets the same posts is a little bit.. timewasting.
Keep an eye on this topic from now on!
And enjoy!