I shared my user.conf a while back with the guys on the xROM thread. I got really positive feedback from them so I decided to share it in a few other threads. JAC is included a lot of my ideas in xROM 1.4 and is going to include more in 1.5 It has grown and become more popular so I decided to start a thread at the request of a few people who use my config.
I didn't think it deserved the space until now to make a thread so I never started one. I'm not trying to make this thread all about me. I've said more than once, I would love for someone to come up with a config that is better than mine because I will be the first one to use it. I just don't want to keep derailing other conversations in other threads anymore. And while I appreciate all of the emails that I get, I think a separate thread will be an easier place to discuss this and help people out.
So I will start by posting giving a general outline of how I came up with my settings. If you want to give me feedback, I appreciate it. Even if you have emailed me in the past or posted something on one of the threads I would appreciate a post in this thread. If only the people who have problems post here I won't know how many people it is helping or not.
That is only part of the thread though. If you have a configuration that you have seriously tested and you want other people to try it, post your method and how to set it up and let's see what we can come up with. Please don't just post random configs hoping someone else will test them for you. I don't want the thread to turn into a confusing mess that doesn't help anyone. My goal is to have this thread spawn some new ideas that will make everyone's phone faster. If you've done your homework and you think you have something good, let's share it. I never thought that my config would be used by so many people. I was just trying to make my phone faster. Maybe you can do better.
Testing Method:
I generally use two apps to benchmark the performance of my phone. They are Benchmark Pi and Benchmark. Both are available on the market. I use Benchmark Pi for a rough comparison because it is faster and focuses mostly on how fast the CPU is running. When I get down to fine tuning I use Benchmark. It takes longer to run but it measure graphics, CPU, memory, and filesystem performance. For Benchmark Pi I usually will run it 10 times and use the average response. With Benchmark I set it to run each bench 5 times each and it automatically averages the values. Then I export that to a csv file and compare them that way.
I think I am a pretty heavy user of my phone so I took what I normally use and added a little bit to it. Here is what I used:
- All testing was done on xROM
- Over 120 apps installed
- 5 home screens
- 18 widgest and 8 shortcuts to apps (I can post specifics if anyone cares)
- I run the phone until it is definitely swapping. I play music, open large web pages, run CPU intesive apps, etc.
- ask me if you want more details
I use Advanced Task Manager, which I highly recommend, to keep an eye on what is running and kill any apps that are not being used by me or my desktop. I try to simulate heavy usage of my phone with only the things running that should be. I also use cat /proc/swaps, free, and sh /system/bin/swap -s (sh /system/sd/userinit.sh -s for othe ROMs).
I started out comparing Compcache and Linux Swap since those are the biggest choices. Compcache came out slightly better with the recommended configs that I could find at the time. Then I benchmarked and tested each of the Compcache settings. I found huge improvements made from tuning Compcache, especially adding backing swap. I know it got a bad rap in earlier builds because, well, it probably wasn't very good. But 0.6 is good and it has a bright future. Read this article http://lwn.net/Articles/334649/
Then I tuned swapiness, CPU, and tried on VM. It was mostly just painstaking, tedious testing of one setting to the next. I can honestly say that I have tuned every setting in the User.conf. If I change any of them the benchmarks go down. So when people tell me they tweaked this or that I don't want to say anything because I have probably tested that exact scenario and I got worse performance. But maybe it is working for them, I haven't seen any benchmark numbers. I tried on the VM but nothing seemed to help very much and I didn't want to cause problems so I stuck with the default settings there. Maybe someone can come up with better settings for the VM if that is their area of expertise.
Results:
I'm not going to post some grand report like I would at work. I'm not getting paid for this. Plus not very many people would look at it and I don't know how much it would mean in the long run.
The easiest comparision I can make is using Benchmark Pi. The average of all of the users who have ever tested using that app is around 15 seconds to calculate pi. Stock G1's will calcluate it in about 16 or 17 seconds depending on how loaded they are. xROM stock was getting a result of about 13.5 seconds with just scaling the CPU up to 528 MHz. After tweaking all of the other settings I got down to sub 12 seconds. My best time is about 11.6 seconds. I saw someone with 11.5 who used xROM 1.4. When I loaded CM 4.0.4 last night I was getting just under 13 seconds with my best times. Still a very good time considering everything that I have running.
I did a lot of other testing with Benchmark to monitor the filesystem and memory. I monitored /proc/swaps to see how much memory Compcache was using and how much was being swapped.
I learned a lot about the phone doing all of this. For instance, when you set the CPU max threshold really low, it is going to keep bumping up the CPU really fast until you get to the max. So you have a pretty good delay until you get to the max CPU frequency because the fequency keeps changing and pauses when that happnes. But then it is good until it drops again. If you make it too high, it will overwork the processor and you will see delays again. The key is to find the best setting that allows the processor to be exercised but not overworked. I don't have the time to write down everything I learned from it and you probably don't want to read it. But if you ask a specific question I will be happy to answer it.
I'd like to thank Huanyu for his thread (http://forum.xda-developers.com/showthread.php?t=542899). I wouldn't have been able to tune any of this without it and for JAC and Manup for helping me so much with xROM.
I hope this thread is helpful. Let me know what you think of my work and post your ideas too.
I have links to installing my User.conf in my signature. This post is long enough without putting that in here too. And this is more about discussion than pushing my settins on people. I don't know if mhy config will work at all with Hero. I haven't done much testing on it. I plan to do the same project for Hero when I have time. JAC has volunteered to help me out with that. If anyone wants to try it, go for it. But I don't want to confuse this thread too much by discussing Hero and the AOSP ROMs. Maybe I will start another thread for just Hero.
I look forward to seeing where this thread goes.
Ok, I decided to add more now that I have some extra time. I'm working to get backing swap working with a swap file instead of using a swap partition. A lot of people don't have or want a third partition on their phone and backing swap helps out a lot. Compcache 0.6 supports this but it wouldn't work on the G1 (or any ARM processor). I opened an issue with the compcache development team. They gave me a fix which allowed me to enable it but it ended up trashing my ext3 partition. I had to wipe my phone because the data became so corrupted. The issue is still open and the compcache developer is working on resolving it. When it is resovled, I will post an updated user.conf file that uses swap file instead of swap partition.
Many thanks for your test.
Just one question, why you don't turn the linux swap on in Cyanogen's ROM?
I found you turn on the compcache and backingswap in user.conf.
Is it better than compcache with linux-swap?
min scaling frequency 192000?
I applied the settings from your user.conf in the Cyan thread you linked to except the min scaling frequency because it seems to be set to a non-existent step (192000). Is that a typo or...? Is that user.conf the latest one you tested with CM 4.0.4?
Thanks for doing all this testing and sharing your settings!
fengwuyu said:
Many thanks for your test.
Just one question, why you don't turn the linux swap on in Cyanogen's ROM?
I found you turn on the compcache and backingswap in user.conf.
Is it better than compcache with linux-swap?
Click to expand...
Click to collapse
Compcache with backing swap uses the linux swap partition but it lets compcache manage both the compressed and non compressed storage. When a file can't or shouldn't be compressed it doesn't have to pass it back to the OS to deal with. It just moves it directly to swap. That is why it shows 100% good compression with backing swap turned on. All of my testing has shown that compcache + linux swap is much slower and more cpu intensive thand compcache + backing swap.
my experiences are non-scientific and completely anecdotal, but I like the way my phone behaves w/ a 92 meg linux swap partition enabled w/o compcache. I'm giving up a bit of responsiveness across the board (once it starts swapping) for more virtual memory. Since I have a class 6 card, the lag is bearable (i can't imagine it would be on a slower one).
I like to have my browser still be in memory after loading terminal, gmail, or a couple of other apps. but that's just me & how i use my phone. it's not a perfect config by any means, but it works best for me
ei8htohms said:
I applied the settings from your user.conf in the Cyan thread you linked to except the min scaling frequency because it seems to be set to a non-existent step (192000). Is that a typo or...? Is that user.conf the latest one you tested with CM 4.0.4?
Thanks for doing all this testing and sharing your settings!
Click to expand...
Click to collapse
It's not a typo. Some of the overclocking apps use it as an option. I've used it for a long time and so have other peole. If you want to change it, that is fine. I used 245760 for a while because of some apps I was running. The CPU frequency is one area that you can play with to meet your needs without changing much. I wouldn't suggest going below 192. You can try it but it makes the phone slow to wake up for some people.
alapapa said:
my experiences are non-scientific and completely anecdotal, but I like the way my phone behaves w/ a 92 meg linux swap partition enabled w/o compcache. I'm giving up a bit of responsiveness across the board (once it starts swapping) for more virtual memory. Since I have a class 6 card, the lag is bearable (i can't imagine it would be on a slower one).
I like to have my browser still be in memory after loading terminal, gmail, or a couple of other apps. but that's just me & how i use my phone. it's not a perfect config by any means, but it works best for me
Click to expand...
Click to collapse
That is a pretty good configuration. You will probably see better performance at a slightly higher swapiness with 92MB of swap. I think around 40 is a good setting.
You are right with a Class 6 card the performance is not that bad. You won't see a lot of lag until the file grows to the point that the OS needs to clean it up to make room for more memory. Then it will slow down. If you reboot every day it's not as much of an issue.
I've tried to come up with a configuration that works well for everyone. I helped a guy with a Class 2, 1GB card last night. He thought that my config was slowing him down on CM 4.0.4. We reparititoned and gave him a smaller ext (256 MB) to free up more memory on his FAT32 partition. I have a lot on my phone and my dalvik-cache is on my ext partition and I am using about 215MB so he should be fine with that setting. He got all of his apps installed and setup everything. Then he tested his it out with the stock settings. After he had an idea of how it was running he switched to mine and saw a noticable improvement. Using Benchmark Pi he had the same score I had with a Class 6 8GB card running on CM 4.0.4 the other day. Now my card will beat him out in other tests. Anything that requires swapping to the linux swap partition or a lot of I/O on the SD card will be better on my phone. But because he was using Compcache his performance was still pretty good.
Also, if you enable backing swap your browser should still be in memory after loading other apps. One of the biggest things people notice is that after they have been using the browser or something else that takes a lot of memory and they hit the home button they don't have to wait for it to reload. It's just there waiting for them.
Yes, he speaks the truth. After updating to a recent Cyanogen ROM, my phone just got super clunky and annoying to use, so I set out to do a completely fresh install: resizing, reformatting, wiping, fresh ROM flash, and fresh app dls. I thought since I was stuck using the stock 1GB SD card (for now at least) that is inherently Class 2, it was causing me a major bottleneck since CC and BackingSwap both employ fair usage of your SD card. Well after updating to Cyanogen's 4.1.2.1 and installing all my apps, Benchmark Pi clocked in at about 15.5ms - 16.5ms using Cyano's stock CC settings built into his ROM. Next I pushed Taylor00's user.conf with the 0.1.4.1 userinit.sh. After rebooting, my phone clocked in at 12.6ms - 13.2ms on Benchmark Pi, a definite improvement.
-Maleko48
miketaylor00 said:
That is a pretty good configuration. You will probably see better performance at a slightly higher swapiness with 92MB of swap. I think around 40 is a good setting.
You are right with a Class 6 card the performance is not that bad. You won't see a lot of lag until the file grows to the point that the OS needs to clean it up to make room for more memory. Then it will slow down. If you reboot every day it's not as much of an issue.
I've tried to come up with a configuration that works well for everyone. I helped a guy with a Class 2, 1GB card last night. He thought that my config was slowing him down on CM 4.0.4. We reparititoned and gave him a smaller ext (256 MB) to free up more memory on his FAT32 partition. I have a lot on my phone and my dalvik-cache is on my ext partition and I am using about 215MB so he should be fine with that setting. He got all of his apps installed and setup everything. Then he tested his it out with the stock settings. After he had an idea of how it was running he switched to mine and saw a noticable improvement. Using Benchmark Pi he had the same score I had with a Class 6 8GB card running on CM 4.0.4 the other day. Now my card will beat him out in other tests. Anything that requires swapping to the linux swap partition or a lot of I/O on the SD card will be better on my phone. But because he was using Compcache his performance was still pretty good.
Also, if you enable backing swap your browser should still be in memory after loading other apps. One of the biggest things people notice is that after they have been using the browser or something else that takes a lot of memory and they hit the home button they don't have to wait for it to reload. It's just there waiting for them.
Click to expand...
Click to collapse
if i notice it being laggy, i just swapoff & swapon and it's like i'm fresh off a reboot.
what would be epic is if someone ported anacron / atd to android -- i could set it to do this at 4am.
alapapa said:
if i notice it being laggy, i just swapoff & swapon and it's like i'm fresh off a reboot.
what would be epic is if someone ported anacron / atd to android -- i could set it to do this at 4am.
Click to expand...
Click to collapse
I believe that crontab is a part of busybox. You can use that.
I'm still not following
miketaylor00 said:
It's not a typo. Some of the overclocking apps use it as an option. I've used it for a long time and so have other peole. If you want to change it, that is fine. I used 245760 for a while because of some apps I was running. The CPU frequency is one area that you can play with to meet your needs without changing much. I wouldn't suggest going below 192. You can try it but it makes the phone slow to wake up for some people.
Click to expand...
Click to collapse
What I'm confused about is the significance of choosing 192000 as a scaling frequency at all. My understanding is that the CPU can only run at certain frequencies and 192000 is not one of them. If you set 192000 as your minimum scaling frequency, doesn't that have exactly the same effect as setting it for 245760? Since there are no frequencies available between 122880 and 245760, any setting (for minimum scaling frequency) between those would default to the higher frequency, in this case 245760. Am I missing something here?
The reason I thought it might be a typo is because there is a 19200 frrequency available, but from all reports anything near that low will just lock up the phone.
ei8htohms said:
I applied the settings from your user.conf in the Cyan thread you linked to except the min scaling frequency because it seems to be set to a non-existent step (192000). Is that a typo or...? Is that user.conf the latest one you tested with CM 4.0.4?
Thanks for doing all this testing and sharing your settings!
Click to expand...
Click to collapse
Here is a copy/paste of that section of the latest user.conf set with MT00's settings:
Code:
#cpu clock
proc_cpu{
proc_cpu_en=1 # enable(1) or disable(0) user cpu configurations
# freqency options
# 19200
# 122880
# 128000
# 245760
# 384000
# 528000
scaling_min_freq=192000 # default 245760
scaling_max_freq=528000 # default 528000
sampling_rate=2000000 # default 2000000 depending on kernel version
powersave_bias=0 # default 0, (200 since CM3.9.6+ )
up_threshold=45 # default 40, percent cpu usage before going up a speed step
While 192000 is not an option listed, here is the output of my userinit.sh:
Code:
C:\Documents and Settings\user>adb remount
remount succeeded
C:\Documents and Settings\user>adb shell
sh-3.2# sh /system/sd/userinit.sh -s
sh /system/sd/userinit.sh -s
=== user.conf ===
*** general ***
apps2sd=0
media2sd=0
*** CompCache ***
compcache_en=1
cc_memlimit=18
cc_disksize=32
cc_backingswap_en=1
cc_backingswap=/dev/block/mmcblk0p3
swappiness=28
*** Swap File ***
swap_file_en=0
linux_swap_file_size=32
linux_swap_file=/system/sd/swap.file
*** Linux Swap ***
linux_swap_en=0
linux_swap_partition=/dev/block/mmcblk0p3
*** VM ***
sys_vm_en=1
page_cluster=3
laptop_mode=0
dirty_expire_centisecs=3000
dirty_writeback_centisecs=500
dirty_background_ratio=5
dirty_ratio=10
*** CPU ***
proc_cpu_en=1
scaling_min_freq=192000
scaling_max_freq=528000
sampling_rate=2000000
powersave_bias=0
up_threshold=45
=== CompCache status ===
CompCache version 0.6+
Compcache enabled
CompCache: MemLimit 18432(system) 18432(user)
CompCache: BackingSwap /dev/block/mmcblk0p3(system) /dev/block/mmcblk0p3(user)
CompCache: cc_swappiness - 28(system) 28(user)
=== CompCache status output ===
BackingSwap: /dev/block/mmcblk0p3
DiskSize: 32130 kB
MemLimit: 18432 kB
NumReads: 8048
NumWrites: 10222
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
NotifyFree: 3870
PagesDiscard: 0
ZeroPages: 177
GoodCompress: 100 %
NoCompress: 0 %
PagesStored: 4340
PagesUsed: 1060
OrigDataSize: 17360 kB
ComprDataSize: 4078 kB
MemUsedTotal: 4240 kB
BDevNumReads: 1233
BDevNumWrites: 1731
=== VM status ===
Set VM: page-cluster - 3(system) 3(user)
Set VM: laptop_mode - 0(system) 0(user)
Set VM: dirty_expire_centisecs - 3000(system) 3000(user)
Set VM: dirty_writeback_centisecs - 500(system) 500(user)
Set VM: dirty_background_ratio - 5(system) 5(user)
Set VM: dirty_ratio - 10(system) 10(user)
=== CPU status ===
Set CPU: scaling_min_freq - 192000(system) 192000(user)
Set CPU: scaling_max_freq - 528000(system) 528000(user)
Set CPU: sampling_rate - 2000000(system) 2000000(user)
Set CPU: powersave_bias - 0(system) 0(user)
Set CPU: up_threshold - 45(system) 45(user)
That setting seems to take.
You can set the frequncy to 1234 if you want to. I wouldn't recommend it but you can. I don't know why it isn't listed as an option. It should be. It is a valid setting.
miketaylor00 said:
You can set the frequncy to 1234 if you want to. I wouldn't recommend it but you can. I don't know why it isn't listed as an option. It should be. It is a valid setting.
Click to expand...
Click to collapse
You actually cant set the frequencies to any arbitrary number. There are a set of defined frequencies in the arch/arm/mach-msm/clock.c file. So you can't try to clock your CPU at let's say 523.12 or 99.8 mHz atm. Unless that frequency table is expanded to include every single frequency. Where's coolbho3000 he might be able to explain it better. lol
After the phone has rebooted you can use the following command to see if everything is running properly:
Code:
su
sh /system/sd/userinit.sh -s
Everything seems to work right for me on the install but after I reboot and enter this code. I get "sh: Can't open /system/sd/userinit.sh".
Does this mean it did not work?
bigragu said:
After the phone has rebooted you can use the following command to see if everything is running properly:
Code:
su
sh /system/sd/userinit.sh -s
Everything seems to work right for me on the install but after I reboot and enter this code. I get "sh: Can't open /system/sd/userinit.sh".
Does this mean it did not work?
Click to expand...
Click to collapse
Which ROM are you on? Different builds require the userinit in different places.
Have you done this?
Code:
su
cd /system/sd
chmod 755 userinit.sh
chmod 755 user.conf
reboot
overground said:
Which ROM are you on? Different builds require the userinit in different places.
Have you done this?
Code:
su
cd /system/sd
chmod 755 userinit.sh
chmod 755 user.conf
reboot
Click to expand...
Click to collapse
I'm on CyanogenMod v4.0.4. I clicked the link from this post which lead me to the code he had posted in another thread. I followed the instructions there. I don't believe the code was exactly what you have here. Will try. Thanks.
andonnguyen said:
You actually cant set the frequencies to any arbitrary number. There are a set of defined frequencies in the arch/arm/mach-msm/clock.c file. So you can't try to clock your CPU at let's say 523.12 or 99.8 mHz atm. Unless that frequency table is expanded to include every single frequency. Where's coolbho3000 he might be able to explain it better. lol
Click to expand...
Click to collapse
That is not true at all I just set mine to 192123. Are you telling me that is in the clock.c file?
Code:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq;
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq;
192123
bigragu said:
After the phone has rebooted you can use the following command to see if everything is running properly:
Code:
su
sh /system/sd/userinit.sh -s
Everything seems to work right for me on the install but after I reboot and enter this code. I get "sh: Can't open /system/sd/userinit.sh".
Does this mean it did not work?
Click to expand...
Click to collapse
Most likely you don't have a userninit.sh. If you are on CM 4.x it doesn't come by default. Follow the steps in this thread:
http://forum.xda-developers.com/showthread.php?t=542899
Related
ok its simple we all know the benefits of more ram. we all know that android slices up the ram into static addresses within the kernel. i would like to change that as we are in 2009 almost 2010 and we still rely on static ram allocation for the camera, gpu, sensors, radio. the g1 has 192mb of ram. yet we only get 97 for programs to use. i would like to place the camera, gpu, etc into dynamic addresses that we can change within the os without flashing a new kernel. a service, kernel code, module, or any other method could do this. we just have to make it happen. we could do it three ways i see.
1. a system managed ram allocation using a service to detect the percentage used and increase ram on the go.
2. a kernel script or service that only activates and allocates ram when needed. such as once a 3d program is loaded the 8mb magically comes back.
3. a virtual device ram allocation service that makes the device think it has the ram all along, but only actually gets it when it needs it. kinda like the way apps2sd works.
4.(by IConrad01) run perl scripts through ase and use ksplice to patch the gpu1 memory in kernel. one script on and one for off.
any other methods to implement this proper are very welcome and encouraged.
the idea behind this is a proper way to get back more ram for our programs. the idea is simple when 3d is not in use we can used the 8mb it would have used for something else. this applys to everything that has its own ram. camera, etc. say we did this and only got 120 free. thats almost 25% more ram. plus we could go the extra step and let the user choose how much each thing gets(gpu settings 4mb,8mb,12mb. camera on, off. etc) so when it needs it thats what it gets. great if you like/dislike 3d games.
on another note this is the kind of work that gets you noticed. the kind that gets you hired or gets you respect. google would be proud and might implement it and you and i know it. i hope we are successful and google uses it mainstream.
so lets debate a way/ways to do this
provide alpha tests of different ways to do this
and finally lets post a beta so everyone can enjoy.
atm ksplice with perl scripts is where we are going will update as this progresses.
Doesnt Jacs update to his hero rom have this, im probably mistaken
jad011 said:
Doesnt Jacs update to his hero rom have this, im probably mistaken
Click to expand...
Click to collapse
No. The current implementation of this basically cuts the graphics memory in half.
This would dynamically allocate the memory as needed. Much more efficient way of doing it.
he has a static change that takes the ram away from the gpu by a kernel edit. this is to have both more ram but still give the gpu what it needs to perform properly but only when it needs it or you chose to give it.
Are you referring to RAM or storage space? You say RAM in the title but then it sounds like you're talking about storage space before making me think it's RAM again later on. I'm confused :/ I'd really like additional free RAM, anything that helps reduce swapping to SD card is good but storage space I have plenty of.
all of this would apply to ram only. swap and compcache could use the same idea to dynamically allocate swap but that is still a cache for programs. sorry if its confusing. simple way to explain. i want all the ram i can get but still use everything the phone has properly, like games and the camera.
Gotcha and understood. I see so many people say RAM and memory when they're referring to storage space sometimes that I want to scream but extra RAM on the G1 would be more than welcome. Hopefully others with the brains to make it happen can do it
actually anyone with a basic knowledge can help. mostly there are a couple things to developing a good idea.
first the concept.
then ideas on how to do it.
next a map or guide to what does what.
coding different parts
putting them together
debug and test
even if all you do is photoshop the ui or provide ideas it helps. once some different people get aboard this should be working sooner than you think.
Of the three options listed, the kernel script (via ksplice) seems like it would be the shortest route to functionality, but frankly it also seems a bit... well, hackish -- when compared to the virtual device allocation scheme. It would take a hefty re-write of the kernel, I suspect, to accomplish; but being able to resize various devices on the fly would be a good thing. Shrinking CompCache based on real RAM usage for example would probably speed up the phone under light loads.
Just thinking in text here.
personal i think its going to start simple(script or root app) and go straight to gpu shared on or off. choose and reboot. however i do not want to stop there like winmo did. someone could create a short kernel patch that checks for a service or script and gets value or defaults to standard method. then we would have to come up with how to manage the switch(realtime vs. reboot) ideally we would remap the memory from scratch and rebuild the memory management services to dynamically allocate the ram for all devices(128+ ram) as needed. we have a start, we know where and how to turn the gpu1 shared on or off. now lets make it more than a hack and work on how to make our phones better. btw this is not a waste of time. this extends to other phones and the future way to set up our phones from default.
jokersax11 said:
personal i think its going to start simple(script or root app) and go straight to gpu shared on or off. choose and reboot. however i do not want to stop there like winmo did. someone could create a short kernel patch that checks for a service or script and gets value or defaults to standard method. then we would have to come up with how to manage the switch(realtime vs. reboot) ideally we would remap the memory from scratch and rebuild the memory management services to dynamically allocate the ram for all devices(128+ ram) as needed. we have a start, we know where and how to turn the gpu1 shared on or off. now lets make it more than a hack and work on how to make our phones better. btw this is not a waste of time. this extends to other phones and the future way to set up our phones from default.
Click to expand...
Click to collapse
The only problem with this is when the ram is divided, everything in it is cleared, thats why it is set at boot in the kernel. Think of it like repartitioning your SD. Now it would probably be possible have everything mapped to ONE big RAM table & then build something similar to a scheduler like BFS for RAM that would allocate it as necessary. This is messy though.
Just my $.02
well yes but it is possible to create shared memory through c++ http://www.go4expert.com/forums/showthread.php?t=8461
however i think the vm heaps has either a 6 or 16mb limit. anyways the service would basically do a memory patch over the kernel in realtime(like overclock) telling the gpu the memory is there all the time. meanwhile it allocates dynamic shared memory from the application memory for the gpu to read and write. meanwhile an app tied to a script would set the parameters and settings.
Okay -- I know ksplice works with perl; and I know that we can run perl scripts using the ASE .apk.
So... it seems to me that it /should/ be possible to use a patch that reverts the patched kernel back to the previous state, and a patch that switches the original state to the GPU1=0 MB state. From there, we could set up two scripts; one for GPU1-off and one for GPU0-on. Each would simply be an invocation of ksplice to input the specific patch (which would have to be stored on the sd card. [it would be safer if in the ext partition]).
We'd have to set up a secondary RAM device, rather than just adding it to the standard RAM pool... something like establishing it as a /dev/block/shm.
The point of all the above is that when you click on the GPU1-off script, it "reclaims" that RAM and gives you a device that's standard RAM. When you click on the GPU1-on script, it disables that device (forcing the reload of all programs using that RAM) and re-enables the GPU1 device.
Even better yet, the Android Scripting Environment program, much like GScript, supports desktop icons.
So -- very initially speaking, assuming we can get ksplice working on Android (which just requires a static binary, IIRC), we can get a simple pair of icons; one of which frees up the GPU1's RAM; and the other of which re-enables the GPU1.
Since the only times it's going to be "called up" are when a game is actively being played, or something similar, this should be a mostly-satisfactory route to begin with, before we can get into the whole scheduled/scaled script running as a daemon in the background.
Once we get /there/, then we can start looking at true virtual device allocations and shared memory and the like.
Although, I do have to say that I'm not entirely sure how comfortable I am constantly repatching the kernel. Definitely, we're going to want to recommend that people back up their original, unpatched, boot.img files!
IConrad01 i added your method to first post as it was a great start to this project. if you want me to rephrase just post what you want and ill change it. the only issue i might see is what geniusdog254 said it might unallocate the wrong thing and create a reboot. but some clever coding should prevent this.
Nah, that's all good.
There's an easy way to prevent it from becoming a reboot-able issue. Enable the GPU-space device as "swap". This could be done one of two ways; tell the phone that the new 8 MB RAM "device" is to be considered the /first/ swap device to be used, and just leave it "as is". The r/w times would be for true RAM. The other option assumes we have the latest CompCache (0.6+) -- as it allows for multiple instances of CompCache. The theme here should be obvious.
Either way, the result is that only swappable pagefiles would be lost when the device is turned back into GPU memory. No system-vital memory would get tossed. Seems simple enough to accomplish, perhaps. But then again, I Am Not A Programmer.
ok so what are the alternatives to ksplice for the swap device change. since we could make it swap/compcache anyways is it possible to change on the fly like the way overclocking widget does?
Ksplice allows you to make kernel updates and have them implement themselves without having to reboot the device. The swap device stuff would have to be implemented on a script-level. Two different things: I.e.; the script invokes ksplice to install a specific patch, which causes the kernel to recognize the newly freed-up RAM as a specific device (I.e.; such as /dev/ram1 as opposed to /dev/ram0). I am not sure I'm saying/thinking of this properly here: I'm operating on the edge of what I know about Linux.
Anyhow -- the trick is, when we get the kernel to disable the GPU's memory, we enable a new RAM-disc swap partition with its swappiness set to the maximum rating so it picks up everything first. Since it is /actually RAM/, it'll perform like real RAM. We're only 'declaring' it as swap in order to prevent forced reboots when turning it off.
The above wouldn't just be a ksplice thing; ksplice is just to implement daproy's kernel patch and thus free up the devoted memory to the GPU1. This memory would then be allocated to a new device (thus preventing the RAM-dump forced reboot) and /that/ would be set to swap status to ensure no "mission-critical" files go on it.
Then, once we get that built up, we just build it in "reverse" -- turn off swap (dumping its info back to the system, where CompCache / linux-swap would pick up the load) and re-enabling the GPU1.
Once we get /those/ built, we can then create a daemon script, include an invocation of it into the latest userinit.sh, and have that script basically monitor GPU0's load levels. If they go above a certain threshold (scaling, just like with the CPU), it would invoke the second script above, patching the kernel and re-enabling GPU1. This would then monitor the GPU, and once //its// memory load falls back down to where GPU0 can handle it all, turns GPU1 off and frees that RAM back up for individual use.
I can already foresee a complication where turning GPU1 off "on the fly" would cause a reload of all graphics, but... considering how rare it is to even pull a load above what GPU0 can handle in ordinary use, this isn't much of an issue. It'd take some tweaking and beta-testing (which I'm pretty much set to be a tester of at this point, apparently ) but that would be about it.
Now, //ideally// we could create an alternative solution which wouldn't rely on constantly patching the kernel. As I said; that can get... well, "messy".
I just don't know enough to know what that alternative path would be. Virtual shared memory space seems like it would be a good idea. An alternative solution could be something along the lines of enabling GPU1 at all times and simply having it call to a swapfile which is located in /tmp (I.e.; a non-compressing swap-file which is actually located in RAM). Said swapfile could be resized freely according to need and would thus be no issue at all.
Frankly, I can already see one reason why that would be a superior solution to all the ksplice shenanigans above: said swapfile could be made to be /larger/ than 8 MB, and thus actually provide for an increased performance due to higher available memory for the graphics side of things. We'd want some way to make sure that the swapfile itself wouldn't get pages dumped onto an actual swap partition. This seems like a much more elegant solution than the ksplice routine. I simply have no idea if it's even feasible. The swapfile would have to be mounted into /tmp (or it's Android equivalent) //at the time the GPU1 was enabled//. Is that even /possible/ at boot? Could we simply enable the device very late in the boot stage?
Quickly! Someone with /actual programming expertise/, rescue me from my aimless mental tinkering!
Since it seems there's little activity in this thread, I thought I'd share:
There is a debian armel package for ksplice.
( http://packages.debian.org/squeeze/ksplice )
This is ARM-compiled. We would simply need to cobble together a script which invokes ksplice properly. I myself know nothing of how this would be done.
Usage example of ksplice here:
http://www.ksplice.com/example-update
Looks pretty simple. You just need a working kernel build environment. Anyone got one of those laying around? I have wanted to do that for awhile but am too lazy to set up a linux VM, lol.
Hell yeah!!
Im not much good for this project other then willingness to try betas and give feedback, but I'm excited to see where this goes.. It would be great to reclaim the ram being used from the system when you aren't using anything that needs it and use it for what you are using. Has anyone contacted one of the devs that have been modifying the kernels and ask them if they could try building it with the ksplice functionality?? I would think one of them would be happy to build it so you can start playing with it. Wish I could help more on it, but this is a little above my head, but I will be following this thread and learning what I can as i go.. Good Luck!!
Hey everyone,
With the intro of BFS302 and Cyan's almost stable rom, I figured it is time to do some testing w/ user.conf files on CM 4.1.99. I feel this is necessary because I notice that after ~12 hours or so, the phone really starts to lag and I have a suspicion it has something to do w/ compcache.
I WAS using the stock CM 4.1.99 setting (24mb compcache), and now I am trying a user.conf that uses 64mb compcache w/o backing swap.
Anyone have any good settings\configs that have worked well for them AFTER SEVERAL HOURS OF USE?
The phone always seems to be quick after bootup and a taskkill, but after a few hours (possibly when compcache gets full) it starts to act sluggish
EDIT: Now that 4.1.999 is out, what is everyone using for user.conf settings?
EDIT2: Now that 4.1.9999 (and possibly more to come) is out, what is everyone using? I have added the corrected userinit.sh and my current conf file for reference if anyone wants.
zimphishmonger said:
Hey everyone,
With the intro of BFS302 and Cyan's almost stable rom, I figured it is time to do some testing w/ user.conf files on CM 4.1.99. I feel this is necessary because I notice that after ~12 hours or so, the phone really starts to lag and I have a suspicious it has something to do w/ compcache.
Click to expand...
Click to collapse
You are starting this testing thread on a ROM that has broken BFS and Compcache. This has been reportedly fixed by Cyanogen for the next update. Maybe it would be best to wait to try this when compcache is working efficiently again.
Oh, well thats good to hear. Hadnt heard anything about BFS or compcache issues yet. Anyway, guess we can continue testing once the new update comes out today.
Well to answer your question though, miketaylor00's user.def script has been working really well for me since I started using it...
http://forum.xda-developers.com/showthread.php?p=4334135#post4334135
Here's mine (Unix formatted, open in Notepad++). Running great on CM 4.1.99 for almost 2 days now w/o rebooting. Everything's still smooth and responsive.
Here are the highlights:
...
# 32MB cc with 24MB backing swap on Linux-swap partition
compcache_en=1
cc_disksize=32
cc_memlimit=24
cc_backingswap_en=1
cc_backingswap=/dev/block/mmcblk0p3
cc_swappiness=60
...
# swapfile off
swap_file_en=0
...
# swap partition off
linux_swap_en=0
...
# Defaults here
proc_cpu_en=1
scaling_min_freq=245760
scaling_max_freq=528000
sampling_rate=2000000
powersave_bias=200
up_threshold=40
...
I've also had good results with up_threshold set at 32. I'm also running the "extra memory" kernel hack, so that might be a contributing factor.
After messing with user.conf last night and all day yesterday, it seems the best solution is to just disable CC and enable linux swap or nothing at all until the update is released.
Thanks for your opinions and experiences. I have had 2 kernel panics\reboots today using stock settings, switched to a user.conf file I was using before to see if there is any difference. Lookin forward to the new release tonite though
bump because of new update
zimphishmonger said:
bump because of new update
Click to expand...
Click to collapse
Send me the default file and I'll send you my recommendation. I don't have time to load Cyanogen but I've been testing similar ROMs and I am testing the same BFS patch right now. I've found that BFS performs about the same with the same settings whether it is on Hero or Donut or Cupcake. I may not get you the optimal settings but it will be close and you can build from there.
The stock doesnt have a user.conf file, it just enables compcache 24mb by default (I believe). I usually use a slightly modified version of your user.conf file. I changed the cpu to 254760, and the swappiness to 60 (Just changed for testing).
I have a 64mb swap parition on a class 4 SD that is being used as a backing swap. I cant figure out if a backing swap is helping or not, as the lag happens after being booted for 8+ hours (usually overnight)
zimphishmonger said:
The stock doesnt have a user.conf file, it just enables compcache 24mb by default (I believe). I usually use a slightly modified version of your user.conf file. I changed the cpu to 254760, and the swappiness to 60 (Just changed for testing).
I have a 64mb swap parition on a class 4 SD that is being used as a backing swap. I cant figure out if a backing swap is helping or not, as the lag happens after being booted for 8+ hours (usually overnight)
Click to expand...
Click to collapse
Keep the 64MB swap and try the settings from JacHeroSki. See how that runs for a while. What are you using for your CC memlimit? Are you still having problems on the 999 build?
miketaylor00 said:
Keep the 64MB swap and try the settings from JacHeroSki. See how that runs for a while. What are you using for your CC memlimit? Are you still having problems on the 999 build?
Click to expand...
Click to collapse
Havent seen any issues on 999 build yet, but as I said, it happens after a while (when the compcache gets full and uses the backing swap, I assume). Anyway you can post the user.conf for jacherski? Is it different then xROM1.5r4 or r3?
Regarding CC_memlimit, I am currently using 24. Recommended?
zimphishmonger said:
Havent seen any issues on 999 build yet, but as I said, it happens after a while (when the compcache gets full and uses the backing swap, I assume). Anyway you can post the user.conf for jacherski? Is it different then xROM1.5r4 or r3?
Regarding CC_memlimit, I am currently using 24. Recommended?
Click to expand...
Click to collapse
Yes, BFS completely changes the game with the user.conf. Try this one out. The format might not be right so you will probably need to just copy the settings over. That's why I was going to have you send the original. I'm too lazy/busy to download and extract the CM file. But here is my BFS user.conf. I'm betting the upped CC Memlimit will probably help you out quite a bit.
Much appreciated, will 'convert' it and let ya know how it works out over the next day or so. Lookin forward to playing w/ the new xROM whenever that comes out
Zim, did you see my post in the Compcache vs. Linux vs. Stock thread? If not, check it out. It explains it a little better. I should start another thread on tuning BFS ROMs and post what I know. JacHeroSki is so fast that I'm using it as my daily ROM now. We just need to make it more stable and it will be perfect.
miketaylor00 said:
Zim, did you see my post in the Compcache vs. Linux vs. Stock thread? If not, check it out. It explains it a little better. I should start another thread on tuning BFS ROMs and post what I know. JacHeroSki is so fast that I'm using it as my daily ROM now. We just need to make it more stable and it will be perfect.
Click to expand...
Click to collapse
I agree, BFS really has given Android a whole new lease on life. So snappy. I would love to use JacHeroSki full-time, but I rely on a Bluetooth headset occasionally, so thats a deal killer....but I do have a switchrom image that I continually update to see whats new
Will check out that post, but you should start another thread about tweaking specifically w/ BFS. Seems to be gaining universal acceptance in the community, and it def changes the game around.
zimphishmonger said:
I agree, BFS really has given Android a whole new lease on life. So snappy. I would love to use JacHeroSki full-time, but I rely on a Bluetooth headset occasionally, so thats a deal killer....but I do have a switchrom image that I continually update to see what you new
Will check out that post, but you should start another thread about tweaking specifically w/ BFS. Seems to be gaining universal acceptance in the community, and it def changes the game around.
Click to expand...
Click to collapse
I'm really interested to see how those settings run on the latest Cyan. I have been wanting to tune it but I haven't had the time. That ROM is a lower priority for me because only a handful of people seem to want me to offer my suggestions on it. Cyanogen seems to want to stick to compcache only so I've left it alone for the most part.
copied and updated my user.conf file. Seems a lil more snappy right off the bat now. Will report back w/ long term results.
I currently use Cyanogen full-time, but I do occasionally have a habit of switching back and forth to xROM.
zimphishmonger said:
copied and updated my user.conf file. Seems a lil more snappy right off the bat now. Will report back w/ long term results.
I currently use Cyanogen full-time, but I do occasionally have a habit of switching back and forth to xROM.
Click to expand...
Click to collapse
Could you upload your updated user.conf file?
sacredsoul said:
Could you upload your updated user.conf file?
Click to expand...
Click to collapse
I am messing around w/ some Hero stuff at the moment, so I cant access my user.conf. Its pretty easy to modify miketaylor's previously released .conf, however. Ill attach my previous user.conf and you can just take the setting from miketaylor's attached one (above)
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 ...
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
Reserved - 10 char
Reserved - 10 char again ...
Changed the name to get more attention. Surprised that no one gave a comment about it
Appreciate any comments or criticisms or correction of what I've written here.
Thanks!
Excellent Read!
Thank you very much!
carnagecjb said:
Excellent Read!
Thank you very much!
Click to expand...
Click to collapse
Glad you enjoyed it
this is actually really helpful. half the time I really didnt know what I was messing around with thanks.
Dataslycer said:
this is actually really helpful. half the time I really didnt know what I was messing around with thanks.
Click to expand...
Click to collapse
Cool Glad that you liked it.
Hope this gets more attention as I would want it to be beneficial to people who uses tweaks and to know how to use them
Nice read Mate. I used to wonder about I/O schedulers and which one to use etc. I like to add build.prop scripts and int.d scripts. This thread just helped me to understand more about it.
Thanks!
read every word, thank you very much. I'll be talking to my kernel dev about BIGRAM... on miui our 720p recording doesn't work right anyways. Thanks again for the great info.
Sent from my MIUI SCH-i500
ShyamSasi said:
Nice read Mate. I used to wonder about I/O schedulers and which one to use etc. I like to add build.prop scripts and int.d scripts. This thread just helped me to understand more about it.
Thanks!
Click to expand...
Click to collapse
Thank you for reading. Hope the knowledge comes in handy when you tweak your phone
sageDieu said:
read every word, thank you very much. I'll be talking to my kernel dev about BIGRAM... on miui our 720p recording doesn't work right anyways. Thanks again for the great info.
Sent from my MIUI SCH-i500
Click to expand...
Click to collapse
Wow, great! Hope you enjoy reading it as much as I enjoyed writing it
having trouble with your thunderbolt tweak. I downloaded the file for I9000 placed it on my phone (SD card) mounted my system and data in recovery mode then proceeded to install the thunderbolt zip file. Using script manager i found the bolt_scripts file and ticked the run at boot button. Then i hit the run button and got 14 permission denied messages asking are you root. Do i have to run this as root. Might be a dumb question but im very new to trying this. Thanks
kevnac said:
having trouble with your thunderbolt tweak. I downloaded the file for I9000 placed it on my phone (SD card) mounted my system and data in recovery mode then proceeded to install the thunderbolt zip file. Using script manager i found the bolt_scripts file and ticked the run at boot button. Then i hit the run button and got 14 permission denied messages asking are you root. Do i have to run this as root. Might be a dumb question but im very new to trying this. Thanks
Click to expand...
Click to collapse
Yes, you need to run everything as root . Scripts in init.d would already be running as root. You just need to make sure Script Manager is running as root for the remount script
Excellent thread, very well written, had a quick skim read, but I'm going to take some time tonight to absorb it all ;-).
Thank you!
zeekiz said:
Excellent thread, very well written, had a quick skim read, but I'm going to take some time tonight to absorb it all ;-).
Thank you!
Click to expand...
Click to collapse
Cool Thank you for reading such a long article
Let me know if you have any questions or if you think I made a mistake
superb thread !
testomat said:
superb thread !
Click to expand...
Click to collapse
Thank you for reading
testomat said:
superb thread !
Click to expand...
Click to collapse
+1
10 chars
rom-g said:
+1
10 chars
Click to expand...
Click to collapse
Thank you for the support
Remember to have the screen turned ON while you apply the script!!!
Hi guys!
Today i want to share with you a script i specifically tailored for our 4C, to decrease high battery drain just by tuning parameters of the interactive governor.
As many of you know, on the Nexus 5X forum there is a huge post about different profiles created to achieve the same purpose, and almost all of them works with our device (personally tested)
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life!
I raccomed to read it!
One of them in particular was extremely good battery wise but i felt some lagginess here and there (talkin about HawkTail 1.2)
So i decided to make a script myself and share it with you, the idea behind it is to force the CPU to scale better with loads and making the Big cores in use more frequently by tuning some of the kernel parameters.
Plus we will have the GPU idling @ 180MhZ instead of 300MhZ (like in the Nexus 5x) and a switch to noop scheduler.
Performance wise and taking in example the latest stable ROM from Xiaomi.eu (8.0.5) we will have a decrease of about 5k point in Antutu (I'll attach two screenshots, the 71K was the result without tweaking, plus just by switching back to CFQ scheduler you'll get 2K points back but NOOP is more battery friendly)
So here you go, this is my script TAO.
Using it is pretty simple and you have a couple of options: [ROOT IS NEEDED]
Since it's a script, if your rom have INIT.D folder support, you can just move the file under /etc/Init.d and reboot the device. The script will make a log file under /sdcard/TAO.log that you can check if anything went wrong.
The second option, if your rom doesn't have Init.d folder support, just use Kernel Auditor and a text editor.
Open the downloaded file in a text editor, select all and copy the text.
Then open Kernel Auditor, and in the menu look for init.d, enable the "Emulate Init.d" and then click the "+" symbol. It will ask to add a name (let's set it to TAO for coherence), then OK. It will open a new window where we have to paste all the text previously copied, save it by pressing the icon on the top right. Now we can just reboot the device or click the newly created item and select execute.
Third option is to run it manually from terminal.
Plus, i'll add my Thermal-engine-8992.conf that you guys can use to change the thermal throttling values. Download it and replace it in /system/etc/ , set it with permission 644 and reboot.
This modded thermal will move up the limits, long story short, your device will continue to perform even if it gets hot.
Enjoy! & report back for feedback
Remember to have the screen turned ON while you apply the script!!!
P.S.
Files are zipped, extract them!!!
UPDATE
Minor update - use_sched_load set to 0 for both cores
Correction made for the log file
UPDATE 0.7
Since @solis_f is having some problem with the big cores, and this could be a common problem to many others too i've decided to add something in the script that will force the big core online so you should not have any more problem executing the script. Let me know
UPDATE 0.8 - Experimental
Updated Target_loads for both Little and Big cores.
Little core min freq. to 384 MhZ.
Input boost @ 787 MhZ instead of 600 MhZ.
hispeed_load disabled for both cores.
Updated values for UpMigrate.
Enabled core_ctl for big cluster:
With this update, you'll have your big cores Offline most of the time, but they will comes online when needed.
Yours perfd (/data/system/perfd/default_values) with this version have to look like this:
Code:
ihf;787200
iahd;38000
ighl;200
itl;39 460800:5 600000:62 672000:10 787200:81 864000:90 960000:99
gpu_default_pwrlvl;5
sst;33
smil;20
sminr;3
sitl;65
sum;66
sdm;54
cbmf;1525
cbhdr;90
cbhip;16
ihf0;787200
iahd0;38000
itl0;39 460800:5 600000:62 672000:10 787200:81 864000:90 960000:99
imst0;0
ighl0;200
imf0;0
itr0;30000
its0;-1
iiib0;1
intb0;0
ibd0;0
ihf4;1248000
iahd4;38000
itl4;53 768000:64 864000:72 960000:79 1248000:99
imst4;0
ighl4;200
imf4;20000
itr4;30000
its4;-1
iiib4;1
intb4;0
ibd4;0
P.P.S.
Over two hundred downloads, but not even half of you gives me feedback...
UPDATE 0.9
Sorry for the delay, many things to do IRL.
This version is what i'm using now, should be smoother then v0.8, hope you like it.
nice one, will try this
Did you try to run Antutu several times in a row, so we can see is the result of 66k almost constant. Since as we all know, results can degrade towards 44k because of overheating..
predragiPredrag said:
Did you try to run Antutu several times in a row, so we can see is the result of 66k almost constant. Since as we all know, results can degrade towards 44k because of overheating..
Click to expand...
Click to collapse
I did not, but degradation of score is dictated by the thermal config. That's why i modded that too, and pushed the standard limits...
Let me show you with an example:
Code:
[SS-SKIN-XO-THERM-PERF]
algo_type ss
sampling 250
sensor xo_therm_buf
device cluster1
set_point 43000
set_point_clr 37000
time_constant 0
device_max_limit 800000
This is taken from the original file, and it covers the big cluster... when it reach 43° celsius, the thermal throttling will limit the max frequency of the cluster to 800MhZ
Code:
[SS-SKIN-XO-THERM-PERF]
algo_type monitor
sampling 5000
sensor quiet_therm
thresholds 46000 48000 50000
thresholds_clr 44000 46000 48000
actions cluster1 cluster1 cluster1
action_info 1632000 1248000 960000
This is the same part but modified by me, i've added more step... as you can see thermal throttling for big cluster will work once the big cluster reach 46° and it will cut the max frequency to 1632MhZ, then at 48° 1248MhZ and at 50° at 960MhZ
The hot-plug, that put the cores offline, on the original file for the big cluster is marked at 42° for core 4 and 45° for core 5.
On my config file both cores will be hot-plugged once they reach 52°.
TL;DR if you use my thermal-engine conf file, you will get more consistent score on several runs.
Nice to hear that will try this when I have more time to play with my phone and report back.
Great work and thanks for sharing this
GoldGanja said:
Hi guys!
Today i want to share with you a script i specifically tailored for our 4C, to decrease high battery drain just by tuning parameters of the interactive governor.
As many of you know, on the Nexus 5X forum there is a huge post about different profiles created to achieve the same purpose, and almost all of them works with our device (personally tested)
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life!
I raccomed to read it!
(...)
Enjoy! & report back for feedback
P.S.
Files are zipped, extract them!!!
Click to expand...
Click to collapse
Hi,
I can not apply root because of he problem between pokemon go and root, (I am playing pokemon go with my 8 years old son a father-son activity and he loves it)
I am using a dev miui rom and i did tune my thermal-engine and remove the input boost using the TWRP file manager to apply the files.
This rom does not have init.d folder could i call your script from init.qcom.post_boot.sh? if so, do you know how to?
best regards,
John
You should look for some sort of systemless root, and magisk to masquerade root and be able to play Po Go on a rooted phone. I don't think you can chain load the script within post_boot.sh and by the way to modify it you should have super user permissions. Anyway keep up the father and son activity, is way more important!
Sent from my Mi-4c using Tapatalk
GoldGanja said:
You should look for some sort of systemless root, and magisk to masquerade root and be able to play Po Go on a rooted phone. I don't think you can chain load the script within post_boot.sh and by the way to modify it you should have super user permissions. Anyway keep up the father and son activity, is way more important!
Sent from my Mi-4c using Tapatalk
Click to expand...
Click to collapse
thanx, my son does not talk about anything else...
About the chain load the TS rom does that with ts_power.sh file.
Code:
# ts power scripts permissions
chown -h system /system/etc/ts_power.sh
chown -h system /data/ts_power.sh
Code:
# Call ts_power.sh, if found
if [ -f /data/ts_power.sh ]; then
logi "Call /data/ts_power.sh set_profile $profile"
sh /data/ts_power.sh set_profile $profile
elif [ -f /system/etc/ts_power.sh ]; then
logi "Call /system/etc/ts_power.sh set_profile $profile"
sh /system/etc/ts_power.sh set_profile $profile
fi
I will try to see if it works using your script.
About systemless root, i don't want to be in the middle of the cat and mouse thing. Today google update and tomorrow there is another hide root.
I did replace the thermal engine using the twrp file manager. It works.
Nice share bro. Thermal engine + init.d script is good battery backup for mi4c.
Hello,
could you make patched files available and the place where they should be placed ?
I don't want to root my phone but I want to give your optimisation a try. It is possible with TWRP to replace the files in the file manager. More work but it can be done without root. Therefore however I will need the allready patched files....
A little more "complicated" even... might it not be possible using TWRP to flash these files ? I have no idea how that would work exactly but I can imagine it would be possible to create a flashable zip that replaces these files... It currently goes beyound my abbilities though unfortunatly but maybe someone can help with that.
Thanks for your share @GoldGanja , looks interesting.
But i think the thermal-engine.conf would cause more overheating as it is already (for me reduce overheating is the most important), but i like the way to reduce the clockspeed step by step. Maybe i will try it with lower values.
The modified governer looks great. I think this will help with heating too. But on this there aren´t laggings ?
Thank you! i hope this fix my battery drain and the heat, i'll report if i see changes
@nachtwacht
Even if i make a zip file to use with twrp, this will only be useful for the thermal-engine conf file...because the other one is a script i've created and so there is no other file to replace. As stated ROOT is needed, i'm sorry.
@Danny94
thermal-engine.conf per se will not increase or decrease over-heating, of course one could make a conf file to be more restrictive on the temps and brutally decrease the performance but i don't see the need of this because i don't have any over-heat problem within my device with the script i've made. A major cause of over-heating is the input-boost frequency that by default is set to 1248MhZ, while if you run my script it will be 600 MhZ. Farther i have no lags at all...give it a try and report back. More feedback I have about it, the better I can adjust some parameters.
@HYBRIDEMON
Thanks!
@GoldGanja
Yeah i will try tomorrow if i get some free time.
Wich Rom do you use ? I have at almost all roms overheating problems. After 10 min+ of 3d gaming i have ~55°c + (On my old phone Thl 5k i could play the same game hours, don´t get over 45 °c and no lagging or something - and yeah its not the best phone).
With your thermal config the device throttles later. So it will heat higher, until it shut down big core etc. As hotter it becomes as more difficult its to cooldown. Sure if you won´t reach 52°c would be perfect one. But maybe i will replace the values with lower, else it looks very good.
I can't find tao.log at sdcard.
Script is applied or not?
I copied to etc/init.d and set 755 permissions.
Edit:
Finally I applied manually and I have 2 errors with big cluster settings.
Enviado desde mi Mi-4c mediante Tapatalk
@dany94
I'm using last stable from xiaomi.eu (8.0.5). Anyway, if you get to know how the gears of the thermal engine works, do what is best for your usage. Feel free to change the numbers on my file if needed
siba01 said:
I can't find tao.log at sdcard.
Script is applied or not?
I copied to etc/init.d and set 755 permissions.
Edit:
Finally I applied manually and I have 2 errors with big cluster settings.
Enviado desde mi Mi-4c mediante Tapatalk
Click to expand...
Click to collapse
I think you are using a CM TS rom, right? well, for that you have to do two things.
First, set the battery mode to QUICK, because on BALANCE there is the hotplug of the BIG cores. Then re-run my script.
If that's not the case, maybe the device was just a bit hot, and the hotplug kicked in by the thermal-engine...let it cool down first or use my thermal-engine conf.
Second, rename my file to userinit.sh and place it under /data/local if you want the settings to be applied at each boot.
GoldGanja said:
Even if i make a zip file to use with twrp, this will only be useful for the thermal-engine conf file...because the other one is a script i've created and so there is no other file to replace. As stated ROOT is needed, i'm sorry.
Click to expand...
Click to collapse
Maybe I was not clear or, more likely I do not completely understand which is a fact for sure
Let me clear up the first part, then hopefully in the end I will also better understand
Your script chances several files if I understand correctly ? scaling_min_freq for example is the first one you change in the script ?
Could we not update all the files that you change using TWRP ?
My guess is, (that's just me trying to understand better.....) that I think that using TWRP it is possible to change these files without root, but in reality it is not because the phone is not rooted ? Maybe because only the complete system can be changed and not single files ? (without root)
I do know that in the end, for me it is possible to root my phone, apply the settings, and then unroot it again.... which hopefully have my phone working like it never was rooted... it's just a risk I would like to avoid if in any way possible, therefore I am investigating and trying to get it all clear for me, sorry for that
GoldGanja said:
@dany94
I'm using last stable from xiaomi.eu (8.0.5). Anyway, if you get to know how the gears of the thermal engine works, do what is best for your usage. Feel free to change the numbers on my file if needed
I think you are using a CM TS rom, right? well, for that you have to do two things.
First, set the battery mode to QUICK, because on BALANCE there is the hotplug of the BIG cores. Then re-run my script.
If that's not the case, maybe the device was just a bit hot, and the hotplug kicked in by the thermal-engine...let it cool down first or use my thermal-engine conf.
Second, rename my file to userinit.sh and place it under /data/local if you want the settings to be applied at each boot.
Click to expand...
Click to collapse
I'm using Resurrecction Remix.
Thanks for your answer.
Enviado desde mi Mi-4c mediante Tapatalk
I was pretty sure you will do such a good job for Mi4c! Well done!
Edit: btw big cluster values are not getting applied
solis_f said:
I was pretty sure you will do such a good job for Mi4c! Well done!
Edit: btw big cluster values are not getting applied
Click to expand...
Click to collapse
What ROM are you using?
Sent from my Mi-4c using Tapatalk
Fire are so cheap, that's great,but it's so slow even for normal task.
Long time ago,I have found the performance Bottleneck
Of fire is RAM,not CPU,at least for daily normal use like browser web.when I open more than 3 app like chrome videos music play store,the fire become so slow even get stuck, that's really bad.so the problem is It run out of RAM.it only has 1.7G ram for hd 10 and 1.4g for hd 7 or 8. That's really small today.here is solution I found , it's amazing efficient,really make your fire usable even you run many many apps simultaneously.
One word is "swap".
Swap can make you disk storage to be used as RAM,we know disk is slower than RAM,but as I have test, it's OK,you can do it. : )
First get your fire rooted
Next download a terminal I recommend termux,a powerful tool.
Open temux,now you can run many Linux command on you ,run following command:
su
dd if=/dev/zero of=swap bs=200m count=20
mkswap swap
swapon swap
you will creat 200m*20 about 3.5G ram,also,it takes up the same amount storage,but it worth.
to check if you turn on swap run follow command:
exit
free -m
You'll see you ram status include swap
if you dont ru su before,you dont need exit command beacause you are normal user
swap make big diff experience on you fire, now try it
i can run firefox snd chrome and many app at same time at a acceptable speed.amazing!!!
you will
This is my first share on XDA,I think it's really useful, hope help you too : )
iuyals said:
Fire are so cheap, that's great,but it's so slow even for normal task.
Long time ago,I have found the performance Bottleneck
Of fire is RAM,not CPU,at least for daily normal use like browser web.when I open more than 3 app like chrome videos music play store,the fire become so slow even get stuck, that's really bad.so the problem is It run out of RAM.it only has 1.7G ram for hd 10 and 1.4g for hd 7 or 8. That's really small today.here is solution I found , it's amazing efficient,really make your fire usable even you run many many apps simultaneously.
One word is "swap".
Swap can make you disk storage to be used as RAM,we know disk is slower than RAM,but as I have test, it's OK,you can do it. : )
First get your fire rooted
Next download a terminal I recommend termux,a powerful tool.
Open temux,now you can run many Linux command on you ,run following command:
su
dd if=/dev/zero of=swap bs=200m count=20
mkswap swap
swapon swap
you will creat 200m*20 about 3.5G ram,also,it takes up the same amount storage,but it worth.
to check if you turn on swap run follow command:
exit
free -m
You'll see you ram status include swap
if you dont ru su before,you dont need exit command beacause you are normal user
swap make big diff experience on you fire, now try it
i can run firefox snd chrome and many app at same time at a acceptable speed.amazing!!!
you will
Click to expand...
Click to collapse
Yes, adding a static swap file and adjusting 'swappiness' can make a huge difference in responsiveness, especially when multitasking and after wake from extended sleep when many apps attempt to resync. The file does not need to be large and can be placed in the cache partition if desired.
My recommendations:
- 256MB static swap file
- set swappiness to 10
- leave ZRAM swap intact if present
- (optional) set ZRAM priority higher than static file to favor ZRAM storage
Also no need to use obsecure terminal commands. The free app Apps2SD easily handed swap file creation and management.
Davey126 said:
Yes, adding a static swap file and adjusting 'swappiness' can make a huge difference in responsiveness, ...
My recommendations:
- 256MB static swap file
- set swappiness to 10
- leave ZRAM swap intact if present
- (optional) set ZRAM priority higher than static file to favor ZRAM storage
Also no need to use obsecure terminal commands. The free app Apps2SD easily handed swap file creation and management.
Click to expand...
Click to collapse
Which "Apps2SD" does one download? There are quite a few apps with similar name "App2SD".
Is this the one ?
https://www.apps2sd.info/features
https://play.google.com/store/apps/...rce=Website&utm_medium=Home&utm_campaign=Home
Thank you.
Dan_firehd said:
Which "Apps2SD" does one download? There are quite a few apps with similar name "App2SD".
Is this the one ?
https://www.apps2sd.info/features
https://play.google.com/store/apps/...rce=Website&utm_medium=Home&utm_campaign=Home
Thank you.
Click to expand...
Click to collapse
Yep - that's the pup.
{interesting: name varies depending on entry point; author calls it "Apps2SD" but is posted as "App2SD" in the Play Store}
Oh, thanks so much,you introduce me zram, which a More amazing concept,as I have test,it has better performance than swap,now I change to zram,thx,it's better to my disk
its so good to share,bc i get a better one : )
Does anyone know the PROS and CONS, as far as ZRAM is concerned, between Apps2SD and RAMExpander?
See the following post about RAMExpander:
https://forum.xda-developers.com/hd8-hd10/general/best-optimization-hack-experience-t3730239
Thanks.
Dan_firehd said:
Does anyone know the PROS and CONS, as far as ZRAM is concerned, between Apps2SD and RAMExpander?
See the following post about RAMExpander:
https://forum.xda-developers.com/hd8-hd10/general/best-optimization-hack-experience-t3730239
Thanks.
Click to expand...
Click to collapse
Apples and oranges. Apps2SD is simply a tool that provides GUI for defining and managing static swap files. RAMExpander appears to do the same thing with predefined (and excessive IMO) values. ZRAM is a seperate beast that is best left alone unless one is familiar with Virtual Memory Management and the various interactions that take place between tuneables.
-- I accidentally posted in the wrong thread, sry --
Davey126 said:
Yes, adding a static swap file and adjusting 'swappiness' can make a huge difference in responsiveness, especially when multitasking and after wake from extended sleep when many apps attempt to resync. The file does not need to be large and can be placed in the cache partition if desired.
My recommendations:
- 256MB static swap file
- set swappiness to 10
- leave ZRAM swap intact if present
- (optional) set ZRAM priority higher than static file to favor ZRAM storage
Also no need to use obsecure terminal commands. The free app Apps2SD easily handed swap file creation and management.
Click to expand...
Click to collapse
Is this (attachment) ok?
Oco said:
Is this (attachment) ok?
Click to expand...
Click to collapse
That works! Don't expect miracles. Still a low resource gizmo; reading/writting to static swap is magnitudes slower than memory based zram. But it does allow the OS to swap when needed without thrashing. Setting swappiness to 10 encourages the retention of processes in memory while reducing the chance of exhusting available swap space. If that happens the device will become a complete dog due to thrashing on slow file based swap; a reboot will fix things up.
Davey126 said:
That works! Don't expect miracles. Still a low resource gizmo; reading/writting to static swap is magnitudes slower than memory based zram. But it does allow the OS to swap when needed without thrashing. Setting swappiness to 10 encourages the retention of processes in memory while reducing the chance of exhusting available swap space. If that happens the device will become a complete dog due to thrashing on slow file based swap; a reboot will fix things up.
Click to expand...
Click to collapse
Thanks, is this the same for fire 8 and fire 7?
Oco said:
Thanks, is this the same for fire 8 and fire 7?
Click to expand...
Click to collapse
Yep with caveats. Haven't messed with Fire 8 (2018) virtual memory as stock settings/performance are adequate for my current needs. Wake lag on the HD 8 is non-existent with my app portfolio which was the driver for adding a static swap file on the Fire 7. As a general rule I avoid turning knobs and dials unless there is a benefit that offsets the effort and potential side-effects.
Davey126 said:
Yep with caveats. Haven't messed with Fire 8 (2018) virtual memory as stock settings/performance are adequate for my current needs. Wake lag on the HD 8 is non-existent with my app portfolio which was the driver for adding a static swap file on the Fire 7. As a general rule I avoid turning knobs and dials unless there is a benefit that offsets the effort and potential side-effects.
Click to expand...
Click to collapse
Agreed. While I have no experience with other Fire tabs, the Fire 8 HD 2018 is way better than I expected after reading some of the threads in this forum. I have now disabled the major bloats but find no big difference in either speed or battery drain.
Hi guys. I am late to this thread, of course.
Can anyone tell me how to root the fire 7 9th gen which runs on version 7.3.1.8?
I see that the fire 7 can run way faster because of the methods above but my device can't be rooted because it seems it can't be rooted by where I looked to root it.
All Fire tablets are entry-level that aren't intended for multitasking.
AmznUser444 Dev said:
All Fire tablets are entry-level that aren't intended for multitasking.
Click to expand...
Click to collapse
I see. So you are saying that they can't be rooted? Like the version I have right now? Just wanting to change the swap.
Animate Blade said:
Hi guys. I am late to this thread, of course.
Can anyone tell me how to root the fire 7 9th gen which runs on version 7.3.1.8?
I see that the fire 7 can run way faster because of the methods above but my device can't be rooted because it seems it can't be rooted by where I looked to root it.
Click to expand...
Click to collapse
Try kingroot.
kwanbis said:
Try kingroot.
Click to expand...
Click to collapse
Does it work? Did you have experience of it? I'll see though and come back With some info on it.
Animate Blade said:
Does it work? Did you have experience of it? I'll see though and come back With some info on it.
Click to expand...
Click to collapse
I just flashed LineageOS 12.1 on my two FireHD10. The first one I had blocked the OTA updates so I was able to install TWRP following this guide:
[UNLOCK][ROOT][TWRP][UNBRICK] Fire HD 10 2017 (suez)
Read this whole guide before starting. This is for the 7th gen Fire HD10 (suez). Current version: amonet-suez-v1.1.2.zip NOTE: This process does not require you to open your device, but should something go horribly wrong, be prepared to do...
forum.xda-developers.com
But for the second one, I had forgotten to block the OTA updates so the first step which requires root was not working. I used kingroot to root it first and then followed the guide I posted above.
I did the soft brick to downgrade and then I installed LineageOS 12.1
[discontinued][ROM][unlocked][suez] Lineage-12.1 [05 MAY 2020]
Disclaimer /* * I am not responsible for bricked devices, dead SD cards, thermonuclear war, * or you getting fired because the alarm app failed. * Please do some research if you have any concerns about features included * in the products...
forum.xda-developers.com
I did it 2 or 3 days ago.