Related
Since Sony Xperia X10 is now running on 2.1, topics related to 1.6 is not mentioned here.
This thread are created based on compilation of other threads related to optimization, and meant as an entry point for user interested in optimization.
Understanding your Android
Just to put something short, so we can understand our Android and some points related to optimization better.
Android is an open source operating system owned by Google that is maintained by Android Open Source Project (AOSP). The operating system is based on modified Linux kernel, where most of the application is written in Java language and running on DalvikJVM.
Android do things differently than old generation OS like Symbian, and below is the explanation related to performance.
Unlike Symbian, Android designed to have as many as application loaded and running in the OS, it maintain list of least used application that will be unloaded when a requests for more memory is made when the free OS memory is already low.
These are the nature of JVM, where allocation and deallocation of memory is managed by garbage collector as doing things in bulk is faster then working with small chunks. So you don't have to be alarmed when you open a memory viewer application and see your Android is running on low memory. Freeing RAM with task killer is only momentarily, as you uses the phone again, the free memory will goes down again.
Android phones stores system application, data and files internally in NAND flash area and stores user data in internal memory storage or external storage such as SD cards. This memory is different than your operating sytem memory.
Operating system memory is memory allocated for the kernel, native application and most application you download from market. Installing a lot of application will not directly reduce free RAM, nor uninstalling or removing files will increase free RAM directly. Action such as removing ringtones, wallpaper and even Sony PC Companion ISO will not free your RAM
In general there are two type of android application. One is a standalone application that only run if you open the application, and the other one is running even you haven't open the application which called service.
By design, guideline and suggested practice, application should not continue to run lengthy processing when it get pushed to background via home button, back button or switching to other application; properly build application will just go idle. Which means you should be less paranoid about application eating you processing power.
But service is meant to run lengthy operation as they don't have user interface and runs in background. Some service meanth for pushing or pulling data from internet, reading your files and do processing like playing songs, or just doing something then update the widget just to make you happy. Unnecessary services are the things that you should be aiming if you want to optimize your Android.
General FAQ about Optimizing Sony Xperia X10 2.1
I just updated to 2.1 and my phone really feel slower than 1.6
Since you had been using 1.6 for quite some time, your SD card should have quite a lot of photo and media. Just after you updated to 2.1, and add your Google and maybe Facebook account, the new Face Recognition service is actually already starting to scans all your photo, then when your Google and Facebook contact arrived, it will try it best to match photo and contact. This new Face Recognition really kicks hard in your processor, then after a while your phone will be as fast and even better than old stock 1.6.
I still feel that the phone is slow, is there any simple and quick way to optimize
The simple and quick to optimize your phone instantly is by changing the 2.1 dalvikvm to JIT capable dalvikjvm. You can read and apply them by reading the thread referred below, but before you do that open the below link in background tab and please do read more first.
Android 2.1 OPTIMISER V002 by Jerpelea
2.1 Customizer v0.99.1 by ttxdragon
Both optimizer contains script that will erase your "junk/unused" application from your phone, be sure to read them first before executing. My suggestion is you apply JIT modification first, before going optimizing by remove your "junk/unused" application.
Please do remember that you have to Root your X10 first.
How to root the phone
You can root the phone using methods below.
OneClick z4root Android Application
SuperOneClick Windows Application
Is [INSERT APP NAME] here is save to remove?
By removing unused application, you will gain certain amount of performance gain. Below are the links with app list.
2.1 Customizer v0.99.1 by ttxdragon
Official List of Apps that Can be Removed from a 2.1 x10 by exekias
And still a lot more in other Sony Ericsson X10 forum section but those two is quite complete
And in case you forgot to make backup you can go to
2.1 System Apps - In Case You've Deleted Them by XperiaX10iUser
After doing all that my Quadrant Benchmark is still low
You should run Quadrant as least two or three time or until you get best score, the first one usually yield low score, because a lot of memory allocation process to Quadrant happening during the first run.
Tuning Utilities
Memory Usage - Application to see how much memory used by your application and services
Advanced Task Manager - Application to see is your application running on foreground, background or idle and its memory usage
Quadrant Standard - General benchmarking tools to see if your changes make improvement
Linpack - Processor benchmarking
Titanium Backup Pro - Back up application, the paid version can freeze your app rather then uninstalling it.
Fine Tuning Guide
About Widget, Application shortcut and Live Wallpaper
Even though widgets looks really good in your phone, some widgets required simple periodic process for updating its display, some have a full blown service running to support it. A very instant example that you can see in your phone is the Power Control widget and the new Status Switch widget.
Power Control widget update triggered by configuration change such as wifi on and off, while Status Switch widget which have a battery level is triggered by a running service. Just put Status Switch widget then go to Settings -> Application -> Running Services. Then you will see there a Status Switch Update service running in background to update the battery level.
By selectively put widgets on your home screen, you can gain extra processing and memory. Timescape widget is even worse, it have three service running to support it.
Application shortcuts also uses extra memory in your home screen app and your home screen app is usually system persistent, reducing number of shortcut will give extra RAM and reducing the required rendering process during scroll.
Live Wallpaper just as the name said looks really nice and require extra memory and process of course.
Tuning via build.prop
Some value can be added and modified into build to increase the performance of X10.
dalvik.vm.heapsize=32m
This will change the maximum memory size per application. If you decrease the value, smaller application starts faster, but big application like games will prone to crash, if you increase the value too much, smaller application takes longer to start, but big application will extra gain benefit from less garbage collecting.
Reference: Test: How changing the max amount of memory per VM Heap can effect your ROM (Cyanogen)
windowsmgr.max_events_per_sec=60
This will change the maximum number of touch screen gesture events per second, the bigger the value, the smoother the scrolling will be
There still some more build.prop tweaks that you can do, but not all of them will be processed by X10 as each device behave differently.
reservation for more article to go
Nice clean guide, should help newcomers. Good work!
synlar said:
Nice clean guide, should help newcomers. Good work!
Click to expand...
Click to collapse
Thanks, but i am quite depressed after reading it my self and found that i make a lot of typo. Had to revise and revise again.. lol.
Nice piece of work there Xeviro..
Can you post your build.prop please i cant find the windowsmgr.max_events_per_sec=60 one in mine.
Wolfbreak said:
Can you post your build.prop please i cant find the windowsmgr.max_events_per_sec=60 one in mine.
Click to expand...
Click to collapse
That one you add by your self to you build.prop. If you look further in google, there still a lot of other build properties that you can set to Android.
There is another way to add and test build.prop instantly by using adb shell command "setprop key value" and "getprop key". Some property will take effect immediately, some require you to reboot.
How do you prove that the windowsmgr.max_events_per_sec=60 actually works? After applying that I tried input benchmark and it still showed 33hz.
ooidort said:
How do you prove that the windowsmgr.max_events_per_sec=60 actually works? After applying that I tried input benchmark and it still showed 33hz.
Click to expand...
Click to collapse
Ok, i just checked, that for this build.prop property to take effect, you need to reboot the device first. I just test on my, giving 10 and 200 in value. With 10, the input benchmark showing less then 20hz most of the time, while with 200 it gives me 40hz+.
Also you can see if you scroll the app list with 10 and 200 value, you can see the difference.
xeviro said:
Ok, i just checked, that for this build.prop property to take effect, you need to reboot the device first. I just test on my, giving 10 and 200 in value. With 10, the input benchmark showing less then 20hz most of the time, while with 200 it gives me 40hz+.
Also you can see if you scroll the app list with 10 and 200 value, you can see the difference.
Click to expand...
Click to collapse
I definitely notice the difference between 10 and 200, but it still doesn't go above 33hz... Maybe it's the framerate cap doing it's thing?
xeviro said:
Thanks, but i am quite depressed after reading it my self and found that i make a lot of typo. Had to revise and revise again.. lol.
Click to expand...
Click to collapse
Good write up! I was actually going to say something about the typos/errors, because I'm a jerk, but, you noticed them too, so I feel satisfied.
I hope people will read your little intro about RAM and realize a task killer's real purpose is to kill rogue services that kill battery.
xeviro said:
That one you add by your self to you build.prop. If you look further in google, there still a lot of other build properties that you can set to Android.
There is another way to add and test build.prop instantly by using adb shell command "setprop key value" and "getprop key". Some property will take effect immediately, some require you to reboot.
Click to expand...
Click to collapse
But where do i need them to add? At Beginning or at End or Middle?
iead1 said:
Good write up! I was actually going to say something about the typos/errors, because I'm a jerk, but, you noticed them too, so I feel satisfied.
I hope people will read your little intro about RAM and realize a task killer's real purpose is to kill rogue services that kill battery.
Click to expand...
Click to collapse
Please forgive my typo and grammars, i life in country where people simplify their way of communication. I cannot talk proper now. hahaha
Wolfbreak said:
But where do i need them to add? At Beginning or at End or Middle?
Click to expand...
Click to collapse
Anywhere
xeviro said:
Please forgive my typo and grammars, i life in country where people simplify their way of communication. I cannot talk proper now. hahaha
Anywhere
Click to expand...
Click to collapse
If i add this to the end of my build.prop my phone does not accept SIM unlock code anymore .... ??
EDIT: Strange, second time it worked ... btw. what is the default value ?
Ive added dalvik.vm.heapsize=32m to see what diff it will make and well..
wow.. it killed my phone.
It will show sony ericsson on the screen when you turn it on and just stay there!
So yeah... how can i fix this?
It's bricked, you'll need to reflash the software!
:-(
OP- Great thread, thank you!
Post on my Rooted 2.1 X10i using Tapatalk Pro and Swype
Yeah i knida noticed...
fixed now but im not trying that heapsize thing again..
Anyone here have the original/untouched nordic build.prop? I'm really appreciate it if you share it here. ^_^
Sent from my Xperia X10i (2.1 and rooted) using XDA app
Seansmit17 said:
Ive added dalvik.vm.heapsize=32m to see what diff it will make and well..
wow.. it killed my phone.
It will show sony ericsson on the screen when you turn it on and just stay there!
So yeah... how can i fix this?
Click to expand...
Click to collapse
Seansmit17 said:
Yeah i knida noticed...
fixed now but im not trying that heapsize thing again..
Click to expand...
Click to collapse
Its working correctly in my phone, and this heapsize settings is the most common one in android modding. you go check google and see the results.
I also attached build.prop from my phone.
Hy everyone,
This Thread is reserved for sharing information about Scripts in Android and how they Tweak the Android system through the Linux kernel and what are requirements of Running Scripts correctly!
Main Goal of Scripts:
Well,Scripts Has a lot of Goals,Such as optimizing,improving and in Some Lines we can say,Scripts can:
-Improve Performance and GUI Smoothness
-Improve Battery Life
-Tweak and Optimize the Android engine!
Requirements of using Some Scripts:
Since Android is Based on Linux,there is a possibility to use Linux Scripts to attempt the Goals Listed before in the thread,and like any Tweak you want to Apply there is some requirements you need to Use correctly those Scripts and some of the Importants are :
-Custom Kernel that support init.d(Custom Kernel=Modified Linux kernel,for example in GALAXY ACE Forums here we have:CF-Root-All CM kernels,etc...)
-Having ClockWorkMod 5 or above to Flash Scripts
-at Least 2 MB free in /system
-Root Access(BusyBox should be included)
Useful Info About Tweaks:
-LMK(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 LowMemoryKiller is actually a feature in the Android OS for better memory management.
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
Journaling/Barriers:
This has been a touchy subject here in XDA for most people who debate about it. Most recently,Some Scripts 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 boot-loops when data is partially written/committed into disk
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.
Busybox
Weel,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 R/W!!
MinFree:
Minfree is part of the Kernel (present on both Gingerbread and Ice Cream Sandwich) and It an Option available in Linux kernel Optimized for Android to Improve MultiTasking and It differs from a Phone to another because of the RAM available in users space.
The Minfree is opefully adjustable Like the LMK to optimize Multitasking to a lot of options(like:aggressive,gaming,balanced,etc...)
The Minfree Option can be Found as a part of Linux Scripts for better RAM management!
Network Tweaks:
Well,in Linux Scripts for Android you can find some Tweaks that increase the speed of you Network Download/Upload and those with various types of Netwoks Like 3G,Wi-Fi,etc...
Build.Prop Tweaks
Well,those Tweaks can generally be found in Build.prop in /system and they are for various improvements Such as allowing Phone to Sleep better,changing wi-fi scan interval,changing window animation delay,some network Tweaks,possibility to change density,etc...
SD Card Speed Fix:
This is a Tweaks that Has the goal of increasing the readahead speed of your SD Card,and that by changing the valories of SD card readahead Like:
-256kb
-512kb
-2048kb
-4096kb
Smoothness Tweaks
Well with the Linux Kernel there is a possibility to add some Tweaks to the Linux scripts and those to optimize the GUI Smoothness and also Lock Home launcher in Memory!!
Credits:
Well,what I can say is that I shared those useful Info after some research and my experience with Linux/Unix,and those some of My main Target that I use to find some of the useful info:
-XDA Forums
-Goolge
Reserved 1
Reserved 2
Sweet
unwritten sentance
Great idea
Sent from my GT-I9100 using xda premium
I still have to learn a lot, thank you, very useful.
Küldve Samsung Galaxy Ace-ről Tapatalk 2 használatával / Sent from Samsung Galaxy Ace using Tapatalk 2
Welcome
kmarci said:
I still have to learn a lot, thank you, very useful.
Küldve Samsung Galaxy Ace-ről Tapatalk 2 használatával / Sent from Samsung Galaxy Ace using Tapatalk 2
Click to expand...
Click to collapse
Your Welcome Dude,I would LIke to share more useful info is the upcomming updates !!
Nice stufff i loved reading it way to go slaid thanks a lot ..
Looking forward to the updates
And will the camera issue be solved in next update?
Plz reply fast
Dragonoid said:
Nice stufff i loved reading it way to go slaid thanks a lot ..
Looking forward to the updates
And will the camera issue be solved in next update?
Plz reply fast
Click to expand...
Click to collapse
Well,About CM7.2 Please I'm waiting I don,'t know If I will get a Cooper of another Device so Please Guys no ETA!
Thnks a lot dude.
Sent from my GT-S5830 using XDA
slaid480 said:
Well,About CM7.2 Please I'm waiting I don,'t know If I will get a Cooper of another Device so Please Guys no ETA!
Click to expand...
Click to collapse
Dude that was a joke...the cm9 camera joke ..take it easy ...i m not asking for eta's
You know you are rooted when you use XDA more than FB
So the dev section here has been active recently with some high quality work, and I am looking to add to the fun
**SEE POST 2 FOR CHANGE LOG**
***VERY IMPORTANT IF YOU ARE GOING TO USE THIS MOD, you need to navigate to the /system/etc folder on your device, and rename the file "init.lge.zramswap.sh" to "init.lge.zramswap.sh.bak" so it does not run at boot.
This is a step by step instruction on how to replace the /system/etc/init.qcom.post_boot.sh file for the LG V10. Be it known, however, that this instruction (and file) can be used with any device running the Snapdragon 808 SoC combo.
What does this do?
Simple. It turns your device into an even more efficient powerhouse. Here are is a list of everything done:
-Interactive Governor tuning for performance and better battery life, a quick description of what I did...
-low load, quick response, low frequency
-high load, quick response, higher frequency
-modified input boost settings for Interactive
-Adjusted GPU target load values
-Switched IO scheduler to noop, and tuned accordingly
-Adjusted minfree values (RAM management, it is a little more multi-tasking friendly)
-Adjusted VM parameters - swappiness, dirty ratios, cache pressure, centisec values, etc (again to complement multi-tasking... your data will hang out a little bit more before being written to disk, but house cleaning won't happen all at once, so there is still good performance and your system won't bog down while it is flushing the toilet)
-DISABLED zRAM!!! - I have no idea why a device with 4 GB of RAM has zRAM enabled. This is purely a waste of CPU cycles and other system resources. You want physical memory, not compressed memory.
-Changed congestion algorithm to cubic (better network performance... assuming the network bandwidth is already there
-Cleaned up the shell file and fixed some errors.
-More to come!
How to do this, we'll just get right to it.
Download this app https://play.google.com/store/apps/details?id=jackpal.androidterm&hl=en
Download this file https://drive.google.com/open?id=0BzM9W6qUvx-gcm1SVDhsTDVWZ3M
And while you are here, check this out, decide which one you want.
http://forum.xda-developers.com/showpost.php?p=66792862&postcount=109
Very important you put the file on the root of your INTERNAL SDCARD!!!
Do not forget to do this.
After you do that, open terminal emulator, and type the following commands in the order they are presented (I would highly recommend just copying them from this post and switching back and forth between your browser and the terminal app):
Code:
su
Code:
cd /
Code:
mount -o remount,rw /system
Code:
cd /system/etc
Code:
rm init.qcom.post_boot.sh
Code:
cd /sdcard
Code:
mv init.qcom.post_boot.sh /system/etc
Code:
chmod 0644 /system/etc/init.qcom.post_boot.sh
Double check the file has been replaced with a file explorer of some sort, double check permissions, then reboot. Good to go.
Some of this stuff explained http://forum.xda-developers.com/tmo...nux-virtual-machine-explained-part-1-t3386956
CHANGE LOG***
May 1, 2017
-Pretty major overhaul of the file. I've done some stuff on the Axon 7 that has been pretty effective. Rolling those changes out to other devices. https://drive.google.com/open?id=0BzM9W6qUvx-gcm1SVDhsTDVWZ3M
May 31, 2016
-Replaced corrupted files. Good to go now!
Dangerously version (fixed) https://drive.google.com/open?id=0BzM9W6qUvx-gVHBGWEp3QkpURVE md5sum: a632c866e22114c0e18fa335f005293e
May 25, 2016
Quite a bit of changes here...
-VM completely readjusted. vfs_cache_pressure set back to default 100 to fairly reclaim memory pages that have been allocated to block specific data about file location, etc.. there are tons of write ups on this stuff if you guys want to investigate more into what this setting does, how it works. It's basically a fairness multiplier centered around a value 100. + or - that value increases or decreases the probability that the kernel will reclaim those certain memory pages relative to swap.
-Swappiness reduced drastically... from 80 to 40 (default is 60 depending on which kernel you are running)
-dirty ratio and dirty background ratios reduced drastically to avoid massive amounts of data being flushed and causing system hangups when that ceiling is hit. (lol this happened to me... system ran out of mem... *shrugs* I go hard bros)
-Increased the probably of the system to reclaim memory pages, and made a pretty big adjustment to writeback_centisecs and expire_centisecs
-Changed functional aspects of the interactive governor again - it is perfect. Nominal user experience. Same with touch input_boost. This system definitely has a sweet spot, and I'm pretty sure we've found it now.
-Decided to ditch the laptop mode idea and not mess with the RAM console outputs, the functional loss wasn't returning enough reward. So, here we are.
-Adjusted minfree once more, to
-It is important to note that the system will, admittedly, not multitask quite as aggressively. I had to do this, however, for myself mostly. As I was achieving OOM conditions and hitting the high ceilings set in other parameters like dirty_ratio and when it hits that wall, man it hits hard. Complete lock up for a good 40 seconds while everything is getting dumped from memory. I need a phone with more RAM lol. Didn't think that would ever happen on my mobile set up with 4 GB of it but here we are. I suppose I could re-enable zRAM for myself? But that would hardly help as compression ratios aren't going to yield me an extra gigabyte. Ok now I'm rambling. DOWNLOAD THE FILE!
Very interesting, I'll be trying this in the next hour or so! Thanks for posting.
Edit: Made changes as per the instructions and rebooted successfully. No issues so far, we'll see! Thanks again.
Nice...
Desde V10 (LG-H901)
For all variants? Is it compatible with H961N LP?
Looks promising and wanted to try.
How do I know it worked? I followed the steps
Sent from my LG-H901 using XDA-Developers mobile app
roosxter said:
How do I know it worked? I followed the steps
Sent from my LG-H901 using XDA-Developers mobile app
Click to expand...
Click to collapse
After every line he explains what it does, you would recognize the changes through your usage or maybe non-usage (as far as battery life and RAM management goes)
When I try to move the file it's giving me this error. I have BusyBox and pretty sure it's on read/write access. What am I doing wrong -_-
1|[email protected]:/ # mv init.qcom.post_boot.sh /system/etc
mv: init.qcom.post_boot.sh: remove: Read-only file system
1|[email protected]:/ #
iamtheon said:
When I try to move the file it's giving me this error. I have BusyBox and pretty sure it's on read/write access. What am I doing wrong -_-
1|[email protected]:/ # mv init.qcom.post_boot.sh /system/etc
mv: init.qcom.post_boot.sh: remove: Read-only file system
1|[email protected]:/ #
Click to expand...
Click to collapse
i got problem with the !!!!!!cd /sdcard , writing
i tried cd /storage/emulated/0
and worked for me
11868 said:
i got problem with the !!!!!!cd /sdcard , writing
i tried cd /storage/emulated/0
and worked for me
Click to expand...
Click to collapse
I tried that, but doesn't hurt trying again.
Edit: It worked. I did the same thing lol oh well thanks @11868
Can this be done with the root explorer instead of terminal emulator?
So this can be used on the G4? And does this overwrite settings within the kernel? If I push this file and I don't like the results can I flash a kernel to get rid of the changes?
iamtheon said:
When I try to move the file it's giving me this error. I have BusyBox and pretty sure it's on read/write access. What am I doing wrong -_-
1|[email protected]:/ # mv init.qcom.post_boot.sh /system/etc
mv: init.qcom.post_boot.sh: remove: Read-only file system
1|[email protected]:/ #
Click to expand...
Click to collapse
Your system wasn't mounted as rw when you executed the command
agrenwa said:
Can this be done with the root explorer instead of terminal emulator?
Click to expand...
Click to collapse
It can, yes, I just prefer the old school way. You can manually drop the file in the /etc folder after deleting the previous one. Just need to make sure the permissions are set appropriately.
klbjr said:
So this can be used on the G4? And does this overwrite settings within the kernel? If I push this file and I don't like the results can I flash a kernel to get rid of the changes?
Click to expand...
Click to collapse
Yes, this can be used on the G4 and any other device using the Snapdragon 808. Overwrite settings within the kernel? No, I wouldn't say that. sysfs is more of a userspace / virtual file system that allows you to interact with the hardware... but the parameters we are working with here are completely writable, not permanent, and more important, will reapply AFTER boot. So, no, flashing a kernel will not revert the changes. If you want to go back, you'll need the original file to replace mine with.
Hope this answers your questions.
Since the file is hosted on Dropbox, anyone who has a dropbox account please choose the login option, and transfer the file to your dropbox before downloading it from your own storage to avoid OP's dropbox being blocked for too many downloads in a row.
Good Job OP, nice to see Junior Members doing something great in the dev section
So I did it last night, and so far battery life seems to be much worse than before when nothing has changed but these tweaks. Any idea why? Battery stats is the same for me as usual with the exception of Android System being at 6% and Android OS at 6% use each.
So far so good, not sure what battery usage will be like. I had terrible lag in a game called Underworld Empire and that has disappeared! How badly was the kernel/system coded before?!
Question , how come your file is smaller than the original? Was there a lot of excess code that was useless?
Sent from my debloated rooted LG V10 using Tapatalk
rirozizo said:
Since the file is hosted on Dropbox, anyone who has a dropbox account please choose the login option, and transfer the file to your dropbox before downloading it from your own storage to avoid OP's dropbox being blocked for too many downloads in a row.
Good Job OP, nice to see Junior Members doing something great in the dev section
Click to expand...
Click to collapse
I'll try to upload the file elsewhere, didn't consider that. However, it is a very small file and dropbox might not notice/care. Good observation.
danstheman7 said:
So I did it last night, and so far battery life seems to be much worse than before when nothing has changed but these tweaks. Any idea why? Battery stats is the same for me as usual with the exception of Android System being at 6% and Android OS at 6% use each.
Click to expand...
Click to collapse
Coincidence maybe? Keep monitoring, report back.
Also, bear in mind: rebooting your system causes a little more activity within the OS the first day or so (particularly google services) and it does have an effect on battery drain.
amoot329 said:
So far so good, not sure what battery usage will be like. I had terrible lag in a game called Underworld Empire and that has disappeared! How badly was the kernel/system coded before?!
Question , how come your file is smaller than the original? Was there a lot of excess code that was useless?
Sent from my debloated rooted LG V10 using Tapatalk
Click to expand...
Click to collapse
Yes, it is smaller because I removed everything that was not relevant to the msm8992 SoC. Qualcomm uses common files for just about everything and anything they can - saves them time, hassle and consolidates work somewhat.
Most of the content removed from the stock file is for other platforms not relevant for us.
warBeard_actual said:
I'll try to upload the file elsewhere, didn't consider that. However, it is a very small file and dropbox might not notice/care. Good observation.
Click to expand...
Click to collapse
I recommend Google Drive or Box
@warBeard_actual
Great job buddy on this.... @freeza mad af!
To everyone else I've been using this for a while and am happy to report my buddy warBeard_actual has been killing it!
bencze, proof or it didn't happen
Hello everyone, after a long day of research(googling) and tweaking with various things with this phone I think I may have stumbled upon a way to run our 5Xs in 32-bit mode. In the system folder lies a file called build.prop(Make a copy of this and place it somewhere safe), pull this file and edit these lines:
dalvik.vm.isa.arm64.features=default
dalvik.vm.isa.arm.features=default
and change them to:
dalvik.vm.isa.arm64.features=lpae,div
dalvik.vm.isa.arm.features=lpae,div
after you're done editing push the build.prop file back to the system folder and apply these settings: Chmod 0644 (rw-r-r)
I personally have done this tweak and noticed that even when running heavy apps such as Chrome with multiple tabs open and YouTube while playing 1080p videos in split screen mode that the system always has 400 - 600mb of ram available for use. I would love for a developer to please pipe in and explain what exactly these edits are doing. From my understanding these edits are telling the processor to execute code in 32-bit(exclusively?) instead of the default 64-bit and 32-bit mode. If anyone else is open to try this please give your experiences with this tweak.
Interesting, gonna try this... I guess there's not even a point in having a 64 bit processor with only 2GB of RAM
edit: It definitely feels kinda different... I managed to get Facebook, Messenger, Snapchat, Instagram, Google Photos, YuBrowser and YouTube opened at same time with 281MB to spare.
If anyone is interested to no about Linux.arm lpae here's some information that might be interesting...
Also this is very interesting..
64-bit operation enables applications to use a larger virtual address space. While the Large
Physical Address Extension (LPAE) extends the physical address space of a 32-bit
processor to 40-bit, it does not extend the virtual address space. This means that even with
LPAE, a single application is limited to a 32-bit (4GB) address space. This is because
some of this address space is reserved for the operating system.
• Software running on a 32-bit architecture might need to map some data in or out of
memory while executing. Having a larger address space, with 64-bit pointers, avoids this
problem. However, using 64-bit pointers does incur some cost. The same piece of code
typically uses more memory when running with 64-pointers than with 32-bit pointers.
Each pointer is stored in memory and requires eight bytes instead of four. This might
sound trivial, but can add up to a significant penalty. Furthermore, the increased usage of
memory space associated with a move to 64-bits can cause a drop in the number of
accesses that hit in the cache. This in turn can reduce performance.
The larger virtual address space also enables memory-mapping larger files. This is the
mapping of the file contents into the memory map of a thread. This can occur even though
the physical RAM might not be large enough to contain the whole file.
Does this have any impact on battery? Obviously, just using less memory is good but I'm searching for more battery without sacrificing performances too much.
edoardotavecchio said:
Does this have any impact on battery? Obviously, just using less memory is good but I'm searching for more battery without sacrificing performances too much.
Click to expand...
Click to collapse
To be honest I don't think that it's going to have any significant changes to battery life it's more of a way that the memory management is handled between 32bit &64bit process but I'm no expert..
dog121 said:
To be honest I don't think that it's going to have any significant changes to battery life it's more of a way that the memory management is handled between 32bit &64bit process but I'm no expert..
Click to expand...
Click to collapse
Yes I know but as an information techonology student and Android enthusiast I've found that everything could bring unexpected results lol so I'm Just asking to the OP for some testing
what about stability? apps like play services are made for 64bit devices, doesn't this mod cause stability problems?
edoardotavecchio said:
Yes I know but as an information techonology student and Android enthusiast I've found that everything could bring unexpected results lol so I'm Just asking to the OP for some testing
what about stability? apps like play services are made for 64bit devices, doesn't this mod cause stability problems?
Click to expand...
Click to collapse
Can't answer that .. Can say that it seems to be running with out any issue but I can't even say whether or not these two lines of code are actually taking affect ..After reading a considerable amount of information on lpae I seriously don't think that this is achieving any significant changes to the system management which Is kernel related as far I I know ..But like I said I'm no expert and could be totally wrong
I'm actually really curious as to what effects this could have, and if one could go further toward 32-bit based RAM management. I'm not currently rooted, so I can't modify my build.prop, but I certainly plan to try it soon. As the OP said, I'm wondering if a developer, or perhaps just someone more knowledgable could provide any input as to what this is really doing. Always exciting to find something new!
Should we wait and hope that someone sees this post or maybe PM some of the developers for this device asking for an opinion?
Appreciate the responses guys, I'm hoping that this thread will garner enough attention to get a developer in here and help us out a bit with this.
HesThatGuy said:
Hello everyone, after a long day of research(googling) and tweaking with various things with this phone I think I may have stumbled upon a way to run our 5Xs in 32-bit mode. In the system folder lies a file called build.prop(Make a copy of this and place it somewhere safe), pull this file and edit these lines:
dalvik.vm.isa.arm64.features=default
dalvik.vm.isa.arm.features=default
and change them to:
dalvik.vm.isa.arm64.features=lpae,div
dalvik.vm.isa.arm.features=lpae,div
after you're done editing push the build.prop file back to the system folder and apply these settings: Chmod 0644 (rw-r-r)
I personally have done this tweak and noticed that even when running heavy apps such as Chrome with multiple tabs open and YouTube while playing 1080p videos in split screen mode that the system always has 400 - 600mb of ram available for use. I would love for a developer to please pipe in and explain what exactly these edits are doing. From my understanding these edits are telling the processor to execute code in 32-bit(exclusively?) instead of the default 64-bit and 32-bit mode. If anyone else is open to try this please give your experiences with this tweak.
Click to expand...
Click to collapse
That will not make them run in "32-bit mode" what you can do when compiling is making certain memory calls 16 bit wide and that can actually increase performance in some cases.
I'd done that at compile time for some ROM's and kernels and it does work fairly well while not affecting performance or stability negatively.
LPAE is just a way for 32 bit OS's to acces memory above the 4GB limit, i don't know why you think that would do anything at all. It will literally do NOTHING for a 64 bit kernel based OS and it will have the opposite effect on a 32 bit Kernel OS that has support for LPAE.
Here's a writeup on LPAE http://elinux.org/images/6/6a/Elce11_marinas.pdf
It's a kernel enabled feature in 32 bit systems, if it's enabled it can be disabled in the build.prop but it cannot be enabled since it's enabled by default in 32 bit kernels.
The only thing a 32 bit mode would do is slow down memory access for a 64 bit kernel, it's silly and unimportant since 32 bit code will be run exactly the same except access to anything above the 4GB limit in memory.
---------- Post added at 06:54 AM ---------- Previous post was at 06:51 AM ----------
edoardotavecchio said:
Does this have any impact on battery? Obviously, just using less memory is good but I'm searching for more battery without sacrificing performances too much.
Click to expand...
Click to collapse
Since it is only applicable to 32 bit kernels it won't do anything and won't have any effect on anything what so ever. You can add a line that reads "make.my.phone.fastest=yes" and it will have the exact same effect.
@Nicktheprofessor My post is not directed specifically towards LPAE, it is focused on finding out what exactly these edits are telling the processor to do. The main command if anything is "div" which from my understanding is telling the processor to execute code with 32-bit instructions exclusively instead of the default of executing in 64-bit and falling back to 32-bit when necessary. Thank you for adding to the conversation though.
HesThatGuy said:
@Nicktheprofessor My post is not directed specifically towards LPAE, it is focused on finding out what exactly these edits are telling the processor to do. The main command if anything is "div" which from my understanding is telling the processor to execute code with 32-bit instructions exclusively instead of the default of executing in 64-bit and falling back to 32-bit when necessary. Thank you for adding to the conversation though.
Click to expand...
Click to collapse
OK, let's make sure this is very clear then.
The DIV bit cannot turn 64 bit compiled instructions into 32 bit instructions, it doesn't work that way, the DIV bit is a 64 bit specific instruction set.
Now if you have a 32 bit system with LPAE support you can set DIV to LPAE so that memory addressing can be made using 64 bit memory allocation.
If you have a 64 bit system running a 64 bit instruction set it's on no matter what you do, you need to use a 32 bit instruction set in the code itself to change that.
Here's a very simple explanation: https://www.tptp.cc/mirrors/siyobik.info/instruction/DIV.html
It shouldn't be too hard to rewrite the specific kernel additions and compile it in a 32 bit instruction set but you'd have to provide the LPAE layer to get it to communicate with the 64 bit layer.
What you'd end up with would be horridly slow though and i don't see the point in your endavour, do you even understand the concept of instruction sets?
@Nicktheprofessor Correct me if I'm wrong please. My basic understanding of instruction sets are that they tell the processor how to operate in general and how to execute code to run different software.
As for my endeavor, I'm looking into a way of reducing the system's memory usage as I don't feel that 2GB of RAM for a 64-bit Android system is truly enough. Thanks again though for providing info for me to learn about this stuff.
HesThatGuy said:
@Nicktheprofessor Correct me if I'm wrong please. My basic understanding of instruction sets are that they tell the processor how to operate in general and how to execute code to run different software.
As for my endeavor, I'm looking into a way of reducing the system's memory usage as I don't feel that 2GB of RAM for a 64-bit Android system is truly enough. Thanks again though for providing info for me to learn about this stuff.
Click to expand...
Click to collapse
The point is that you can't run 64 bit native code as a 32 bit instruction set, it is 64 bit as is in source and in it's binary form, it cannot be executed using a 32 bit instruction set. To test this for yourself, try to run 64 bit code on a 32 bit system, it won't work and neither could you run the phone as a 32 bit system executing 64 bit code.
To actually reduce a memory footprint you'll need compilation flags, i suggest using a 16-bit addressing alternative (-mfpu=neon-fp16 -mfp16-format=alternative) instead.
I used to use that on another phone and it did actually help a bit.
2GB is plenty for 64bit though, especially since we're using ZRAM and 64 bit allocations will have higher compression values.
Nicktheprofessor said:
The point is that you can't run 64 bit native code as a 32 bit instruction set, it is 64 bit as is in source and in it's binary form, it cannot be executed using a 32 bit instruction set. To test this for yourself, try to run 64 bit code on a 32 bit system, it won't work and neither could you run the phone as a 32 bit system executing 64 bit code.
To actually reduce a memory footprint you'll need compilation flags, i suggest using a 16-bit addressing alternative (-mfpu=neon-fp16 -mfp16-format=alternative) instead.
I used to use that on another phone and it did actually help a bit.
2GB is plenty for 64bit though, especially since we're using ZRAM and 64 bit allocations will have higher compression values.
Click to expand...
Click to collapse
Ahh I see now, I'm still learning all there is to know about how the Android ecosystem works and I appreciate the responses and info my dude. Addressing your ZRAM statement, I would like to find a way to run this phone without ZRAM and without sacrificing memory space as I notice frequently how slow it is for the phone to push & pull things in & out of swap especially when the swap space is nearly filled.
Nicktheprofessor said:
The point is that you can't run 64 bit native code as a 32 bit instruction set, it is 64 bit as is in source and in it's binary form, it cannot be executed using a 32 bit instruction set. To test this for yourself, try to run 64 bit code on a 32 bit system, it won't work and neither could you run the phone as a 32 bit system executing 64 bit code.
To actually reduce a memory footprint you'll need compilation flags, i suggest using a 16-bit addressing alternative (-mfpu=neon-fp16 -mfp16-format=alternative) instead.
I used to use that on another phone and it did actually help a bit.
2GB is plenty for 64bit though, especially since we're using ZRAM and 64 bit allocations will have higher compression values.
Click to expand...
Click to collapse
I dont understand, if you are using 16bit adress and 64bit words u dont get 2 GB ram..
2^16*64b/8b = 524,288 B of ram...
By the same calculation 28 bits would be enough for 2GB of ram with 64bit words.
If u lower the word size u need more adress space to adress the same memory, so i dont understand why 16bits?
Sent from my Nexus 5X using Tapatalk
InterrtuptoR said:
I dont understand, if you are using 16bit adress and 64bit words u dont get 2 GB ram..
2^16*64b/8b = 524,288 B of ram...
By the same calculation 28 bits would be enough for 2GB of ram with 64bit words.
If u lower the word size u need more adress space to adress the same memory, so i dont understand why 16bits?
Sent from my Nexus 5X using Tapatalk
Click to expand...
Click to collapse
It's known as half-precision floating point and it can improve performance in some cases and save cache space but you still have 64 bit code and 64 bit memory allocation.
You can't fix that without actually rewriting code.
---------- Post added at 03:32 AM ---------- Previous post was at 03:27 AM ----------
HesThatGuy said:
Ahh I see now, I'm still learning all there is to know about how the Android ecosystem works and I appreciate the responses and info my dude. Addressing your ZRAM statement, I would like to find a way to run this phone without ZRAM and without sacrificing memory space as I notice frequently how slow it is for the phone to push & pull things in & out of swap especially when the swap space is nearly filled.
Click to expand...
Click to collapse
Well you could just edit the init files and not have ZRAM at all but still support for it in the kernel, the phone will still work just fine but i sincerely doubt you will see much improvement.
Also the cache speeds are not slow in the least, i don't know where you get that from considering that decompression is done on the fly using the fastest algorithm possible and uses all available cpu's. I don't think you can improve on that much.
SWAP space on this phone is ZRAM, there is no physical memory put aside to do that job so...
However, unchanged code will readily be swapped to disk anyway, that is simply the way the Linux kernel works, it will keep the data in memory and just make a note of the disk address for the unchanged program so perhaps that is what you are talking about?
Nicktheprofessor said:
It's known as half-precision floating point and it can improve performance in some cases and save cache space but you still have 64 bit code and 64 bit memory allocation.
You can't fix that without actually rewriting code.
---------- Post added at 03:32 AM ---------- Previous post was at 03:27 AM ----------
Well you could just edit the init files and not have ZRAM at all but still support for it in the kernel, the phone will still work just fine but i sincerely doubt you will see much improvement.
Also the cache speeds are not slow in the least, i don't know where you get that from considering that decompression is done on the fly using the fastest algorithm possible and uses all available cpu's. I don't think you can improve on that much.
SWAP space on this phone is ZRAM, there is no physical memory put aside to do that job so...
However, unchanged code will readily be swapped to disk anyway, that is simply the way the Linux kernel works, it will keep the data in memory and just make a note of the disk address for the unchanged program so perhaps that is what you are talking about?
Click to expand...
Click to collapse
For improvement in speeds you would see a nice gain if you disabled ZRAM as the recent apps you are using will be in RAM instead of swap(flash storage). We both know that flash storage for as fast as it is is still way slower than RAM. You can test this yourself by disabling ZRAM and setting swappiness to 0 and then opening up a few apps and switching between them. It is noticeably faster. Also, ZRAM compression on the 5X is done exclusively on the small cluster by default (source: https://android.googlesource.com/device/lge/bullhead/+/master/init.bullhead.rc#69)
I understand that swap space is from ZRAM. I also made a mistake with the second part of that statement as I was thinking at the time that ZRAM compresses RAM to use for swap space when it actually compresses some of the flash storage to use for swap space.
ZRAM doesn't use flash.
https://en.wikipedia.org/wiki/Zram
This thread is for the fortunate subset of 5th Gen Fire devices that are rooted and rocking a custom ROM. It should also work on rooted FireOS (5.3.1 and below) that have both ads and OTA updates blocked.
There have been numerous posts regarding uneven performance while multitasking along with sluggish response after waking the device from a long slumber. Most recognize this is due to excessive swapping associated with limited user addressable RAM. While there are a number of incremental 'tweaks' that can marginally improve this behavior my objective was to realize a more substantial improvement with minimal effort, knob turning and side effects. To date I have realized the benefit (minimal lag; responsiveness approaching devices with twice the RAM; woohoo!) but still working on the automation that will make it largely transparent. Lacking the time to work on the latter I thought it best to toss out the high level config and let others, if interested, work through both validation and implementation details.
As an aside, I have used the same technique on a 2nd gen HD running CM 11 that had been shelved for many months due to the same issues. It now hums along at a respectable pace and is once again a joy to use.
The secret sauce is simple: expand zram space allocation and add a small, secondary swap file in a normally unused location in permanent storage.
Tools (or adb/shell/terminal commands for those with furry chests):
- EX Kernel Manager (EXKM) or other tool/technique that can manage zram parameters (note: I find current builds of Kernel Adiutor too unstable for this work)
- Apps2SD Pro or other tool/technique that can create/manage traditional swap files and swap space priorities
- BusyBox Installer (v1.27.2+) or other tool/technique to insure startup scripts are properly executed
- L Speed (optional) - for ease of implementing a few discretionary performance tweaks
- DiskInfo PRO (optional) - visualize partition utilization
- RAM Truth (optional) - simple app to visualize RAM utilization
Technique (highly abbreviated):
- boot device to rooted ROM; install above tools or equivalents
- use EXKM to resize zram to 128 MB (note: zram must be temporarily disabled)
- use Apps2SD to:
* add a static, 128 MB swap file in the cache partition which remains largely unused with custom ROMs
* important: reassign swap file priorities (button at top right): 0 for the static file; 1 for zram
* increase swappiness to 100 if necessary (EXKM can also be used to set swappiness and other VM parameters)
* verify both swap spaces are enabled via sliders
Note to geeks: I understand how swappiness, vcache pressure and other virtual memory tunings really work; let's not debate that here. Same with the merits of running a static swap file in combination with zram or the 'dangers' of placing that file in the volatile cache partition. We're talking a hand held device with very modest resources...not the server room with a 99.9x SLA. Yes, zswap would be better. However ...
Optional tweaks:
- use EXKM or L Speed to set LMK parameters to: 24, 32, 40, 48, 56, 64
- use EXKM or L Speed to set write deferral (aka 'laptop mode') to 5 sec
- toggle KSM off/on in L Speed (sets performance enhancing parameters)
- with zram disabled enable zram tweak in L Speed which will establish a 96 MB space along with other optimizations; I find the smaller size ideal for my workflow; YMMV zRAM size can be set with EXKM or another kernel manager.
Challenges:
While the options exist none of the tools noted above can reestablish custom zram space or automatically create a static swap file on boot. I believe this is a kernel issue but have not ruled out interference by Lineage 12.1 which is the ROM I have been testing with. Unfortunately, I lack the time (and quite frankly motivation) to toss Nexus or another ROM on to a spare device to verify the culprit. I might do a bit more testing my my HD 7 which uses a different kernel and ROM. --> Turns out an old version of BusyBox was the culprit; updating to 1.27.2 solved the problem allowing the suggested configuration to be automatically reestablished on reboot. I added my favorite BusyBox installer to the prerequisite tools.
Another issue is the potential for maintaining 'stale' annon pages in zram for a period of time but that's a left field item that probably won't effect most users. A quick fix is occasionally swiping away all apps.
Provide discussion/feedback in this thread. I may or may not respond depending on available time. I love a deep dive (shared above) but once the goal has been reached my interests move elsewhere.
Edit: struck-out references to L Speed after developer/maintainer acknowledged "cooperation" with Kingo Root team (borderline malware).
Quick follow-up: I continue to enjoy benefits noted in the OP with a dual cache configuration. Device remains responsive after waking and typically returns to 'full' performance within a few seconds. I can easily switch between a handful of apps (browser, mail, Play Store, XDA labs, etc) with minimal lag and context preservation; no reloading web pages after switching away. No notable impact on battery life. Really no disadvantages at all - at least with my work flows.
Regardless of tuning one has to keep in mind the modest hardware resources on Fire 7s. Load up a game or two or a couple heavy Amazon/Google apps and things go south pretty quick. That said, responsiveness far better than any stock config, even when the device is clearly overburdened.
Another quick note. Simply adding a classic swap file (suggest 128 GB) to the largely unused cache partition can yield a decent improvement in multi-tasking performance without the complexity of tinkering with zRAM. All steps can be accomplished with the free tool Apps2SD or equivalent. Happy to document if there is sufficient interest.
Note: Be sure to change zRAM swap priority to "1" so it receives preferential treatment over the classic swap file. zRAM will almost always be faster than classic swap but there is only so much if it. The swap file will be used once zRAM is fully utilized (not entirely accurate but generally true).
FWIW - depreciated references to L Speed app in OP after developer acknowledged "cooperation" with Kingo Root team. While nefarious behavior is unlikely there are other options that avoid any potential conflict of interest.
Davey126 said:
...
Technique (highly abbreviated):
- boot device to rooted ROM; install above tools or equivalents
- use EXKM to resize zram to 128 MB (note: zram must be temporarily disabled)
- use Apps2SD to:
* add a static, 128 MB swap file in the cache partition which remains largely unused with custom ROMs
* important: reassign swap file priorities (button at top right): 0 for the static file; 1 for zram
* increase swappiness to 100 if necessary (EXKM can also be used to set swappiness and other VM parameters)
* verify both swap spaces are enabled via sliders
Note to geeks: I understand how swappiness, vcache pressure and other virtual memory e)
Click to expand...
Click to collapse
When you say Cache partition for the swap file are you referring to "/cache" or the second partition for app2sd?
rjmxtech said:
When you say Cache partition for the swap file are you referring to "/cache" or the second partition for app2sd?
Click to expand...
Click to collapse
"/cache" partition which resides on faster internal storage. Anything on external storage will be significantly slower due to interface limitations.
@Davey126 it has been about a day or two and I can confirm that by following these instructions it has brought new life into my KFFOWI 5th gen. This paired with some L Speed Tweaks (even though you say not to trust them, I opted to use it for a few performance tweaks) and the Lineage ROM from @ggow makes my user experience on the device quite pleasing.
rjmxtech said:
@Davey126 it has been about a day or two and I can confirm that by following these instructions it has brought new life into my KFFOWI 5th gen. This paired with some L Speed Tweaks (even though you say not to trust them, I opted to use it for a few performance tweaks) and the Lineage ROM from @ggow makes my user experience on the device quite pleasing.
Click to expand...
Click to collapse
Thanks for the feedback.
As for L Speed I don't distrust the current developer/maintainer but no longer feel comfortable providing an implicit endorsement. Who you associate with makes a difference IMHO. Each person needs to make their own call. There is no magic in L Speed; it simply offers a convenient UI to various well publicized system 'tweaks' that can be implemented using other tools/techniques.
Davey126 said:
Optional tweaks:
- use EXKM or L Speed to set LKM parameters to: 24, 32, 40, 48, 56, 64
- use EXKM or L Speed to set write deferral (aka 'laptop mode') to 5 sec
- toggle KSM off/on in L Speed (sets performance enhancing parameters)
- with zram disabled enable zram tweak in L Speed which will establish a 96 MB space along with other optimizations; I find the smaller size ideal for my workflow; YMMV zRAM size can be set with EXKM or another kernel manager.
Click to expand...
Click to collapse
Thanks for the guide, it already seems to have helped a lot with smoothness but I wanted to know how to set these options using EXKM.
I'd never heard of the app before today and I've had a good look through the menus but can't seem to find somewhere to set these values. I'm guessing these are the usage % values used by the CPU governor to jump up and down power states?
NeuromancerInc said:
Thanks for the guide, it already seems to have helped a lot with smoothness but I wanted to know how to set these options using EXKM.
I'd never heard of the app before today and I've had a good look through the menus but can't seem to find somewhere to set these values. I'm guessing these are the usage % values used by the CPU governor to jump up and down power states?
Click to expand...
Click to collapse
No, governor tunning is a different beast not addressed in the OP (although I do that on some higher end devices).
With regard to EXKM:
- LMK values can be set under memory -> low memory killer
- KSM toggle can also be found in the memory section
- it appears laptop mode can not be set in EXKM (not that important)
As an alternative to laptop mode you can twiddle 'dirty ratio' and 'dirty background ratio' in EXKM. Suggest setting to 30 and 15, respectfully.
Edit: you may also want to take a peek at Kernel Adiutor (correct spelling). While I find it a bit flaky it exposes more controls vs EKKM and costs less too.
Davey126 said:
No, governor tunning is a different beast not addressed in the OP (although I do that on some higher end devices).
With regard to EXKM:
- LMK values can be set under memory -> low memory killer
- KSM toggle can also be found in the memory section
- it appears laptop mode can not be set in EXKM (not that important)
As an alternative to laptop mode you can twiddle 'dirty ratio' and 'dirty background ratio' in EXKM. Suggest setting to 30 and 15, respectfully.
Edit: you may also want to take a peek at Kernel Adiutor (correct spelling). While I find it a bit flaky it exposes more controls vs EKKM and costs less too.
Click to expand...
Click to collapse
Ah, LMK, not LKM. Thanks again.
Also, just a small suggestion but wouldn't it be better to remove the references to L-Speed and leave an edit message at the bottom rather than having the red, striked through text in the middle?
NeuromancerInc said:
Ah, LMK, not LKM. Thanks again.
Also, just a small suggestion but wouldn't it be better to remove the references to L-Speed and leave an edit message at the bottom rather than having the red, striked through text in the middle?
Click to expand...
Click to collapse
Thanks for noting LKM/LMK typo in OP - fixed that.
I will likely clean-up the OP at some point as there are other refinements (eg: tweaking dirty ratios) that may prove beneficial to a larger community.
Davey126 said:
Thanks for noting LKM/LMK typo in OP - fixed that.
I will likely clean-up the OP at some point as there are other refinements (eg: tweaking dirty ratios) that may prove beneficial to a larger community.
Click to expand...
Click to collapse
I was wondering what differences need to be made for a 7th gen hd 10. I know this guide is written for a 5th gen (1gig RAM, 8 gig drive), but I have a 7th Gen (2gig RAM, 32GIG drive) with 2gig zram (priority 1) and 4 gig swap on the /data partition (priority 2). What would be the best LMK values? Also, is it ok to have the swap on /data vs /cache (my /cache only has 400mb)?
Thanks for any help!
edit: in the OP, it says to set laptop mode using L-speed, and then L-speed is crossed out (I understood why), but no alternative is listed for doing this. I just wanted to add that you can use kernel adiutor to change laptop mode. It's on virtual memory settings.
mistermojorizin said:
I was wondering what differences need to be made for a 7th gen hd 10. I know this guide is written for a 5th gen (1gig RAM, 8 gig drive), but I have a 7th Gen (2gig RAM, 32GIG drive) with 2gig zram (priority 1) and 4 gig swap on the /data partition (priority 2). What would be the best LMK values? Also, is it ok to have the swap on /data vs /cache (my /cache only has 400mb)?
Thanks for any help!
edit: in the OP, it says to set laptop mode using L-speed, and then L-speed is crossed out (I understood why), but no alternative is listed for doing this. I just wanted to add that you can use kernel adiutor to change laptop mode. It's on virtual memory settings.
Click to expand...
Click to collapse
It appears you have priorities reversed. Higher values receive preference. The magnitude of the difference is irrelevant. zRAM is considerably faster than eMMC based storage; the latter should only be used when zRAM is exhausted or momentarily unavailable for whatever reason.
The container sizes also seem excessive. 2 GB of zRAM effectively leaves no uncompressed memory on a HD 10 which is highly inefficient. I wouldn't go over ¼ available RAM or ~½ GB. Toss in a 500 MB of eMMC based (overflow) swap file and you're good to go. If you regularly use more than 1 GB of swap on a relatively low end Android device then something else is amiss.
I am aware Kernel Adiutor can set laptop mode but did not want to introduce another tool into the mix...especially one that has demonstrated inconsistent behavior. FWIW - recent testing suggests 1-2 sec may be a better choice vs the 5 sec mentioned in the OP as the latter may trigger lockouts during sustained writes (eg: large file download on a fast connection). I currently use 1 sec and happy with the results. I will likely update the OP with this info once satisfied that the benefit is worth the effort.
All things being equal I see no reason to change LMK values suggested in the OP. Especially given the availability of zRAM and swap.
Thanks for these instructions, Davey126!
I just tried this process on my 5th Gen Fire 7" which I recently installed with the LineageOS ROM. I was not familiar with the EX Kernel Manager and Apps2D Pro tools, but it was reasonably clear how to make the settings changes you recommend.
I added the 128Mb swap under /cache and increased the zram swap to 128Mb, setting it to priority 1. Maybe it's my imagination but my device does seem a lot snappier when switching between running applications, and better at returning to previously displayed data in applications instead of reloading pages.
Cheers!
Matrey_Moxley said:
Thanks for these instructions, Davey126!
I just tried this process on my 5th Gen Fire 7" which I recently installed with the LineageOS ROM. I was not familiar with the EX Kernel Manager and Apps2D Pro tools, but it was reasonably clear how to make the settings changes you recommend.
I added the 128Mb swap under /cache and increased the zram swap to 128Mb, setting it to priority 1. Maybe it's my imagination but my device does seem a lot snappier when switching between running applications, and better at returning to previously displayed data in applications instead of reloading pages.
Cheers!
Click to expand...
Click to collapse
Thanks for sharing first impressions. Time will tell if the benefits are durable; certainly have been for me with no adverse side-effects.
Another suggestion to reduce wake lag: install Greenify (or similar tool) and add commonly used apps to the action list even if not flagged as background abusers (you may need to override Greenify's sensible defaults via the gear icon). This prevents multiple apps from becoming simultaneously 'active' on wake which is a huge contributor to lag on lower end devices with limited resources (CPU and RAM). Hibernated apps will launch when needed with minimal delay and NO loss of context. Works a treat.
Be sure to add your favoriate browser, mail, messaging and social media apps to the hibernation list as all like to 'check in' after a long slumber.
Although Greenify can auto-hibernate apps on most devices (works best with Xposed Framework) I use an automated approach that invokes Greenify's widget when the screen goes off. There's still some momentary lag on wake but the device remains responsive which is a huge improvement.
Hi Davey126,
thx for the guide, it seems to work awesome.
However, i have the one problem thats the settings in EXKM regarding to "zRAM Size", "dirty ratio" and "dirty background ratio" are lost after rebooting the device. Is there a way to make the settings reboot proof? Interestingly for the "LKM" settings there is an option "Apply at bootime", which does the trick for me, but only for the LKM options.
Kind regards,
Stephan
IronMan1977777 said:
Hi Davey126,
thx for the guide, it seems to work awesome.
However, i have the one problem thats the settings in EXKM regarding to "zRAM Size", "dirty ratio" and "dirty background ratio" are lost after rebooting the device. Is there a way to make the settings reboot proof? Interestingly for the "LKM" settings there is an option "Apply at bootime", which does the trick for me, but only for the LKM options.
Kind regards,
Stephan
Click to expand...
Click to collapse
Likely BusyBox is missing or outdated. Try installing this (I use the pro version).
Davey126 said:
Likely BusyBox is missing or outdated. Try installing this (I use the pro version).
Click to expand...
Click to collapse
Ok. I bought BusyBox Pro and updated to Version 1.28.1-Stericson. Still all settings in EXKM besides LMK get lost after rebooting the device ...
IronMan1977777 said:
Ok. I bought BusyBox Pro and updated to Version 1.28.1-Stericson. Still all settings in EXKM besides LMK get lost after rebooting the device ...
Click to expand...
Click to collapse
- verify BusyBox is property installed w/no conflicting builds
- uninstall/reinstall EXKM
- test if behavior can be duplicated with another (free) kernel manager like KA