Database Users

favorite/best SIMPLE compcache and linux-swap scripts?

I've been playing a little bit with Compcache and Linux-swap on the latest Cyanogen ROMs, but it seems like there are so many variations of these scripts out there that I don't know 100% that the performance I'm seeing is because of the swap method used (compcache, compcache with backing swap or pure Linux-swap) or the particularities of the script. I'd like to set up some Gscripts with the SIMPLEST Compcache, Compcache with backing swap and pure Linux-swap scripts so that I can reboot with no userinit.sh, run a Gscript and see how the phone performs and get an idea of how they each perform with various settings (size and swappiness).
You'll notice that this is NOT posted in the development section, so feel free to explain to me what any scripts you want to share do or don't do. I'm sure others will benefit as well.
Thanks!

not one? (here's what I'm playing with now)
Ok, here is what I am playing with now:
(Generl stuff/mods, mostly commented out.)
Code:
#!/system/bin/sh
uname_r=`uname -r`
moddir=`find /system/modules -type d -name $uname_r`
insmod=/system/bin/insmod
$insmod $moddir/compcache/xvmalloc.ko;
$insmod $moddir/compcache/ramzswap.ko #disksize_kb=32000;
#$insmod $moddir/compcache/ramzswap.ko backing_swap=/dev/block/mmcblk0p3 memlimit_kb=32000;
mknod /dev/ramzswap0 b 253 0;
echo 20 > /proc/sys/vm/swappiness;
#echo 1 > /proc/sys/vm/page-cluster; # default: 3 Changes Page clustering from 8 to 2.
#echo 5 > /proc/sys/vm/laptop_mode; # default: 0 Helps keep SSD from getting worn.
#echo 5000 > /proc/sys/vm/dirty_expire_centisecs; # default: 3000
#echo 800 > /proc/sys/vm/dirty_writeback_centisecs; # default: 500
#echo 10 > /proc/sys/vm/dirty_background_ratio; # default: 5
#echo 16 > /proc/sys/vm/dirty_ratio; # default: 10
echo 2000000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
swapon /dev/ramzswap0;
#swapon /dev/block/mmcblk0p3;
#echo 200 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias;
#echo 128000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq;
#echo 528000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq;
Note: I believe these are correct for recent CM builds with a Linux-swap partition. If you are using anything else, do some research first.

Did you get any testing done on this?
Am interested as well.
(+ If you' re at it test a swap files instead of a swap partition as well, it shouldn't make any difference, see http://forum.xda-developers.com/showthread.php?p=4136554#post4136554)

I played with a variety of different setting with decent results
I wouldn't say that I "tested" any specific settings combinations exactly, but like many I found that Linux-swap set to a relatively low swappiness (20-30) gave me better results than compcache, but that was before switching to the latest Cyanogen ROMs with the tweaked kernel to better use compcache (SWAP_FREE_NOTIFY patch) AND compcache enabled by default. Since then I've mostly been using the ROMs without any userinit because the performance is so good already.
I keep meaning to find a copy of the settings used by miketaylor00 because he seems to think they're quite good (when someone says swappiness 28 works much better than swappiness 30, it makes me think he's tested pretty extensively ), but laziness or apathy has stymied my attempts thus far.

**EDIT**
nm, found infoz already.

[HowTo] Tweak your Archos

Hi,
recently i came upon a thread with someone asking :
how to optimize the archos to be quicker ?
As this is propably a question many people might ask (even I still do ) I thought about creating a thread about. This is not just to answer his question but also for all u nerds out there to corrent me - as I might be wrong in some points AND to gather new options to speed up the device. This is what i have learned yet...
Anyway all of the things I list here require root as far as I know. So get your device rooted or abandon the Thread
ALL THINGS IN THIS THREAD ARE WITHOUT WARRENTY - SO IF YOUR DEVICE STARTS MUTATING INTO A DOG HUNTING YOUR ASS FOR NEW FLESH - BE WARNED
Memory Management:
Introduction: HAVING FREE UNUSED MEMORY ON ANDROID HAS (nearly) NO ADVANTAGE (exception having 0 memory also fu**s up the device -> 1. )
All of those methods wont make your device faster in the meaning of really getting faster in speed... as android already has a quite good memory management.
BUT if u get more space in memory your device can keep more of the apps U LIKE in memory (being inactive according to app lifecycle). This will make them get called faster next time u use them and your device will "feel" faster and more responsive.
1. What should work on all roms are the "minfree" settings -> meaning when android really kills apps - depending on free memory (if u don't know what is mean by - search for the "App Lifecycle" of android)
You can try setting those to the values mentioned by sibere (scroll down) or try finding your own settings. There for u can use any app like "AutoKiller Memory Optimizer" just serach "memory optimizer" in the market.
KEEP IN MIND - you may play a bit with those settings - BUT still u should know what u are doing if u use it!
LOW: If u set the values to low the device will kill apps very late keeping much of them in memory this might make you device get slow. If there is too less Memor fo a "new" app or another process just need more memory while running it has to close down other processes before memory can be allocated.
HIGH: If u set em too high u kill most apps instantly - and your device will get problems and might get unstable as far as i understood.
2. Try gettign more "free" memory by disabeling services - as those got the highest priority they wont get killed that fast by the memory management. For checking u might get an app like "TaskManager" wich lists all running processes.
Just check out what takes your memory and disable those u dont need.U can disaable them by using "Titanium Backup" disable app / uninstall em / or just uncheck their autorun by using a programm like "Autorun Manager". Remember if u just disable the autorun they might (re)start later still.
3. Use a low sceen count in your launcher and keep the widget count low. This is related to 2.) as most widgets run a "background service" to update itself / pulling information (e.g. a waether widget getting latest conditions, a calendar widget keeping connection to your calendar app,...) - each widget took at least 8MB memory when i checked with TaskManager - "greater" widgets like "Fancy Widget (sense like clock and weather widget)" sometimes take up to 25MB
4. DONT USE A LIVE WALLPAPER (live wallpapers use MUCH memory most 20MB-40MB - either they get closed down all the time - or they just reside in memory taking the memory u wanted to use for keeping other apps active)
I also noticed that the App Drawer got "much/noticeable" slower in every Laucher I tested while a live wallpaper was active
5. DO NOT USE A TASK KILLER (remeber the introduction!!! - and think about it yourself - if at least 20 ppl ask why - i write this down here )
6. SWAP / COMPCACHE (can be activated through UD config) - this is a really hard question - those methods extend your memory but the memory u gain is MUCH slower then the internal memory. So again u have to decide and try out if it helps u or it doesn't (I used em long time but never realy felt a big advantage of. Compcache even made my device feel slower and i got more FC's most time - also I tried to figure out how the memory management uses this "memory". But i din't find a clear answer yet - as some ppl mentioned that "inactve apps" wont get swapped - need some clear source... Anway in general those 2 should increase Multitasking capability at cost of speed.
7. FUDGESWAP
- noting yet - its GINGERBREAD only - so we have to wait...
FINALY: u have to decide on your own what u really NEED to run "simultaniously" (I personaly rather have less widgets and run background services like growl, eventghost, tasker) but u can count it yourself by checking back with taskmanager and having in mind your archos (GEN8) just has 256MB of internal memory.
CPU Manaagement:
8. (UD) If u got Urukdroid u can try setting your CPU Governor to another value like:
"Interactive" is more reactive than "on demand" (-> SIBERE)
9. Try an OC (OverClocked) Kernel -> get it in the Urukdroid Dev Thread (I wont link any here as u should know what u do and wich u choose!)
BEWARE not all devices can use an OC Kernel (sadly mine can't) but try it out...
10. Try overclocking your device with the Milestone Overclock Utility. This overclock method is based on a module insert. Again this just works with root.
OVERCLOCKING:
Each CPU is different -> each device is different and can handle different maximum speeds - this is related to the former position of the CPU on its waver while production...
So u have to try out what your CPU can handle safely - so it might happen your device will refuse to boot after u flashed a kernel or set some permanen OC values. Keep a BACKUP or reflash old kernel...
In general u normaly can't brick your device by overclocking as the CPU overheats -> safety function of the CPU stops it -> the device resets itself before the CPU get "burned" (hope this also aplies to ARM processors )
Other:
11. The Launcher: I tested out much lauchers already: ADW, ADW EX, VTL, Laucher PRO, Zeam Laucher, GO Laucher - most of them seem to be eaqual in speed and more differ in features (event Laucher PRO is still the fastest on my Wildfire [but development stopped some time ago], GO seemed to be a bit slower imho) - take any of those but avoid taking some over exagerated 3D'ish laucher like Regina, SPB Shell, Claystone...
12. Apps like "AutoKiller Memory Optimizer" have additionaly features to "optimise" the speed,... u might test those out but I didnt notice a difference most time. Still keep in mind - u should know what u are doing
13. Ok - u may want to hit me for that:
It's more a cosmetic thing - but I recently used UOT Kitchen for theming my framework and used the fly-in animations - and they feel much faster then the default animations just try it out... keep a backup of your original framework for reverting.
All the following Tweaks are mentioned by sibere (credits go to him and propably some other people)
echo "1536,2048,4096,6144,8192,10240" > /sys/module/lowmemorykiller/parameters/minfree
(this is related to 1. ; 1MB = 256 => valueas above are 6MB, 8MB, 16MB, 24MB, 32MB, 40MB)
to enable cgroups cpuacct:
mkdir /acct
mount -t cgroups -o cpuacct none /acct
mkdir /acct/uid
to change ioscheduler:
cd /sys/block/mmcblk1/queue
echo "deadline" > scheduler
cd iosched
echo 1 > fifo_batch
These are lost on reboot so if you wanna keep them, add a script to /etc/init.d
Finaly I also have patched the sqlite library. If you want the file, let me know. It boost a lot SQL database writings. See this thread http://forum.xda-developers.com/showthread.php?t=903507
Click to expand...
Click to collapse
Will ask him to comment on "cgroups, ioscheduler, and sqlite" as im not sure if they work with all rom versions / neither how they work exactly.
THANKS Sibere
EDIT:
aditional threads with tweaks
- Supercharger
- http://forum.xda-developers.com/showthread.php?t=1227269
BEWARE I HAVEN'T HAD THE TIME TO CHECK THEM OUT YET AND DIDN'T TEST THEM
SOME OF THEM MIGHT NOT WORK AND PEOPLEARGUE ABOUT THEM (e.g. the "debug.sf.hw =1" is heavily discussed)
IF ANYONE KNOWS MORE ABOUT THOSE OR CAN HELP TESTING IM HAPPY TO LEARN MORE ABOUT

Hi.
For a full reference to cgroups, you may read the cgroups documentation from the kernel.
Basically, it provides process aggregations in the Linux kernel, mainly for resource tracking purposes.
deadline IO scheduler has been used a lot for SSDs and proven to be quite adapted to flash memory.
The minfree settings set here are pretty much optimised by me for the archos. It gives you a good balance between available cache and free ram . Android starts to complain when the free ram drops below 32Mb. with these settings, the OOM task killer will try to maintain a free ram level above 32Mb. You DON'T need a task killer. It will just use precious ram resources and will mess up with the android integrated task killer.
Those settings are reset on boot, so you may add them in a script added to /etc/init.d/ directory.
SQlite optimisation is of great help and I already posted a lot of information about it when I posted the tweaked file. Please refer to this post. (You'll have to look for it, it's somewhere in the dev thread )
Enjoy your optimised archos!

Thanks guys, learning new tips.

Nice! Good tips. Thanks.

Very usefull reading, thanks!

thanks for the tips ! cheers!

Hello, I am JustLoveJoy, I am an up and coming developer, although I work very hard on my phone right now, my gf has gotten an Archos 8 G2 4GB tablet and I have it rooted but it constantly gives me some issues. Finding this thread, I have to ask, can these or any tweaks be applied to her tablet? is there any source code on github or somewhere else? I mainly wish to get her to be able to do her Farmville on it. I'd like to get on to the development boards with a custom rom for it but I need someone with a little experience to point me in the right direction for that. Thanks So much for starting this thread!

hi i just want to try to root my arnova 7g2 bit i don't find a straight 3d on xda. you clan indicate the right street
Inviato dal mio GT-N7000 con Tapatalk 2

did you notice that crow (CM7) for Gen8 was released ?

still nothing for developing for the Archos 8 G2 4GB? If I can get adb shell I would be happy!

Thanks

thinks man
:good:

Thanks for the great post! I still have one of these!

[Guide] Minicm7 Guide | Bug Fixed | Review | Extra

This is all guide with bug fixing on minicm7 2.1.X​
Screen Cut:
Only in CWM/CWR
NMEAListener:
I think NMEAListener is GPS
I found that gps.conf is europe settings
since that i have no problem with it
for non-europe residence Here Patch
Compass:
Wait till nAa fix
Video Recording Lag:
did you experience this
use this file Download
Auto Brightness:
use this tutorial
Code:
1. disable auto brightness first in display
2. go to cm settings --> display --> automatic backlight --> choose use custom and allow light decrease
3. tick edit other level
4. set number of levels to 13
5. look at this pic [URL="http://attachments.xda-developers.com/attachment.php?attachmentid=874309&stc=1&d=1327627892"]Here[/URL] And [URL="http://attachments.xda-developers.com/attachment.php?attachmentid=874311&stc=1&d=1327627892"]Here[/URL]
6. enable auto brightness in settings (not cm)
7. restart
8. enjoy
Android market app won't show up:
clear data on app settings
Just use recommended tweak:
Non-Recommended tweak make ur phone less stable
Recommended:
SuperCharger
Ram Manager / PRO
Juwe Ram's script
Etc...
Non-Recommended
Build.prop tweak
init.d tweak
IPV4/IPV6
Etc...
End of first post continued in 2nd post ​

Guide for Minicm7​
Notice ADW launcher Lag use this settings:
Code:
1) Screen Preferences - Desktop scrolling speed - set to something low-ish like 150-200, default settings are just plain moronic here. Desktop overshoot should be fine at 30 or 40.
2) Drawer Settings - Horizontal Drawer definite on (this is far superior to the scrolling drawer if you have more than a few apps, and feels much smoother).
3) Drawer Settings - Zoom effect speed - 400 is a decent setting, default was way too high.
4) Drawer Settings - Columns/Rows - 4x4 is a nice setting for portrait, if you don't like a crammed screen.
5) System Preferences - Wallpaper Hack - check this. If you have issues, change wallpapers to something of a sane size.
6) System Preferences - Use Screen Cache - check this.
7) System Preferences - Scrollable Widget support - you should start with this unchecked. Only check it if you have issues with some
Make ur phone fast without tweaks?
here my perfomance settings
Go to CyanogenMod Settings --> perfomance settings
Code:
1.) Set compcache ram usage to 18%
2.) Enable use jit
3.) Disable Surface Dithering (optional)
4.) Enable 16bit transparency
5.) Enable Allow purging of assets
6.) VM heap size 48mb
7.)
SDcard cache size 1024kb Class 1,2
SDcard cache size 2048kb Class 3,4
SDcard cache size 3072kb Class 4,5,6,7,8
SDcard cache size 4096kb Class 9,10
Go to CyanogenMod Settings --> perfomance settings --> cpu settings
Code:
1.) Available gorvernor set to smartassV2
2.) Min Cpu frequency 245mhz
3.) Max Cpu frequency 691mhz+ (optional)
4.) Set on Boot
Make minicm7 more battery save?
here my battery save settings
Note: this settings overwrite "Make ur phone fast without tweaks"
Go to CyanogenMod Settings --> perfomance settings --> cpu settings
Code:
1.) Available gorvernor set to smartassV2
2.) Min Cpu frequency 19mhz
3.) Undervolt
4.) Set on Boot
final step: Delete Unused App
Extra Section​​
Coming Soon
End Of My Post ​

LtHuNTer_StepheN said:
Don't use any tweaks:
tweaks make your phone fast but less stable
and don't use xloud and mobile bravia
they are fake
Click to expand...
Click to collapse
+1 10char..

I agree with other settings, but would you mind explaining why VM heap size is 48? I've read that 32 is better in the FAQ thread of minicm7, and 2048 sd cache cause hiccups while playing music in lower class sd cards, if you can, try to edit some things for lower class cards and higher class cards, for lower class cards 128 sd cache is better and doesnt cause hiccups, just a suggestion . On the other hand, I will try your CPU settings, the smartass v2 settings with min 248mhz and 691mhz, 691mhz is indeed the most stable for nAa kernel. BTW I use tweaks without any stability issues, supercharger v8 and sometimes ram manager pro.
This is the thread that I have read:
forum.xda-developers.com/showthread.php?p=17648469

hixvolnutt said:
I agree with other settings, but would you mind explaining why VM heap size is 48? I've read that 32 is better in the FAQ thread of minicm7, and 2048 sd cache cause hiccups while playing music in lower class sd cards, if you can, try to edit some things for lower class cards and higher class cards, for lower class cards 128 sd cache is better and doesnt cause hiccups, just a suggestion . On the other hand, I will try your CPU settings, the smartass v2 settings with min 248mhz and 691mhz, 691mhz is indeed the most stable for nAa kernel. BTW I use tweaks without any stability issues, supercharger v8 and sometimes ram manager pro.
This is the thread that I have read:
forum.xda-developers.com/showthread.php?p=17648469
Click to expand...
Click to collapse
For Perfomance it's better set 48mb
this help app memory management
this heap size is usefull for HD games
Oh i forgot
i will edit it
for that tweak is already tested
what i say is
Code:
build.prop tweak
mobile bravia engine
and useless tweak
for that tweak it may increase stability
i will edit so people understand

Post Updated
Thanks

Is there any way to fix compass?the compass is somehow inverse

for auto brightness setting, how many level are you using? Ultra brightness enable or not?

Sorry, but screen cutting still exist even with bootanim enabled..especialy when in recovery..
Btw nice thread...^^v
Sent from my E15i using Tapatalk

Post Updated

LtHuNTer_StepheN said:
Post Updated
Click to expand...
Click to collapse
Oops, i'm still using nAa 08...maybe because of that...0_x
Sent from my E15i using Tapatalk

bayumahendra24 said:
Sorry, but screen cutting still exist even with bootanim enabled..especialy when in recovery..
Btw nice thread...^^v
Sent from my E15i using Tapatalk
Click to expand...
Click to collapse
i think screen cut happen with smartass v2

D E V I L said:
i think screen cut happen with smartass v2
Click to expand...
Click to collapse
Flash the new nAa-08b kerner. This fix the problem

Hi!! I have just one question. The tethering wifi always disconnects when screen turns off. I tried wi-fi settings, advanced, never sleep but does not work. Do you have other solutions? Thanks

still score highly!!!
plus avent updated kernel and rarely get screen cuts!!
so id say great rom plus kernel!!

flegga92 said:
Flash the new nAa-08b kerner. This fix the problem
Click to expand...
Click to collapse
Still using nAa 08 (havent change kernel because what i see on the changelog, the difference between nAa 08 and 08b only the screen cuts fix) with:
- Cpu freq 19-600mhz
- smartassv2 on
- undervolt on
- bootanimation enabled
No more screen cuts since my prev post.
Screen cuts SOMETIMES only appear when i'm in cwm req...thats good enough for me..

For the video lag fix,does it work with other rom which have the same problem?flash with xrec or cwm?

Hello to everyone and excuse me if my question is probably going to be dumb (for sure it's an OT so please forgive me about that) but I'm quite clueless about the issue I'm experiencing and I hope to find an advice here.
I own and X10 mini with MiniCM 2.1.6 and 2.6.29.6-nAa-08 kernel. Everyhing's fine, really a great piece of work that has put new life into my beloved X10 Mini but I'm experiencing the 'screen cut' issue that's discussed here too: it happens only with some apps (Labyrinth for example) but it happens and I'd like to get rid of this.
I don't know if it could be an issue related to the apps not being designed for Gingerbread but I don't think so because I expect something different should this be the case.
I've read that the kernel nAa-08b is intended to solve this issue but it seems (maybe I'm wrong) that it isn't suitable for my X10 mini (I've made some digging around and the latest kernel version for my mini seems the one that I've already installed while the 08b seems to be intended for the X8). I'm sure that the reply is already around here but I couldn't succeed in finding it though I've read a lot (really a lot!) of posts here and there, especially on the official thread:
http://forum.xda-developers.com/showthread.php?t=1068553
where unfortunately I couldn't post because I'm a new member with less than ten posts. Some advices? Thanks anyway!

very good guide
thanks you very mach!

post updated
sorry im busy lately

Disable HW overlays + force gpu rendering

What is the purpose/benefit of these options?

Underground_XI said:
What is the purpose/benefit of these options?
Click to expand...
Click to collapse
rendering a view goes through layers or abstractions, even passing through dedicated hardware doing the job. hardware overlay allows the renderer to take a couple of regions aside and treat them optimized. then theres the cpu and gpu. usually android decides which abstraction is best for each view, taking things like transparency into account and what not. you switch hw overlays off, project butter goes out of the window but cpu and gpu still do the job. you force gpu, the composition will be done by your gfx chip. just don't touch it - its meant for developers picking up debugging output.

Root
molesarecoming said:
rendering a view goes through layers or abstractions, even passing through dedicated hardware doing the job. hardware overlay allows the renderer to take a couple of regions aside and treat them optimized. then theres the cpu and gpu. usually android decides which abstraction is best for each view, taking things like transparency into account and what not. you switch hw overlays off, project butter goes out of the window but cpu and gpu still do the job. you force gpu, the composition will be done by your gfx chip. just don't touch it - its meant for developers picking up debugging output.
Click to expand...
Click to collapse
I am rooted, and I'd like to know wether this does improve performance of the CPU cuz the GPU is rendering the stuff. I don't care about the battery.
Thanks in advance

You won't notice any considerable improvements. But can cause unintended side effects in apps (mainly embedded images not displaying)
Sent from my Nexus 4 using xda app-developers app

Make Disable HW Overlays Pernment
View attachment 91fixoverlays.zip
Script To Make Disable Hardware Overlays Permanently On Boot use the script using init.d or script manager or boot shell :laugh:
Code:
#!/system/bin/sh
(while :
do
sf=$(service list | grep -c "SurfaceFlinger")
if [ $sf -eq 1 ]
then
service call SurfaceFlinger 1008 i32 1
break
else
sleep 2
fi
done
) &

Alex240188 said:
You won't notice any considerable improvements. But can cause unintended side effects in apps (mainly embedded images not displaying)
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
dear Mr Alex you are right you may not notice any discernible difference but you free up to cpu to do more especially if you're writing intensive apps.my advice keep it on free that cpu baby

Very nice script. Working nice on 5.1.1

sgatechwork said:
View attachment 2741805
Script To Make Disable Hardware Overlays Permanently On Boot use the script using init.d or script manager or boot shell :laugh:
Click to expand...
Click to collapse
thanks for the script!

Indeed. I specifically logged in, just to be able to thank the dev. I reject the whole "take and run" thing.

Ziontist said:
Indeed. I specifically logged in, just to be able to thank the dev. I reject the whole "take and run" thing.
Click to expand...
Click to collapse
How to run the script?

24imelqui said:
How to run the script?
Click to expand...
Click to collapse
Simple way is to use a working init.d script. Open it using a Text Editor and erase all lines. Copy the lines from sgatechwork to the file and save it to /system/ect/init.d. There are some Apps to emulate init.d if your ROM/Kernel does not support it.
But if you don't know how to use it, why do you want to use it? Do you know what it does?
Thanks @sgatechwork !

24imelqui said:
How to run the script?
Click to expand...
Click to collapse
Odd. I don't recall ever seeing or posting in this thread, and I haven't installed the script. Seems about par for the course for me. Anyways, I read about it, and it sounds like a nifty script. Since you say script (and I would concur, based on the lack of a file ext., and the file size)... it would be placed in the init.d folder in system/etc/init.d, as long as your kernel supports init.d. If not, there are apps to run scripts w/o init.d support. The one I know of is Boot Shell [ROOT]. Also, there's an app that lets you choose which folder you wanna run your scripts from, called init.d Scripts Support. However, the most recommended init.d managing app, based off of what I've read most people recommending, is Script Manager - SManager (there's also a paid ad-free version Script Manager-SManager(NoAds)). Hopefully at least some of this is found helpful. Sorry the response is so late. :?

shaktishekhar said:
View attachment 2741805
Script To Make Disable Hardware Overlays Permanently On Boot use the script using init.d or script manager or boot shell :laugh:
Click to expand...
Click to collapse
Thanks so much, it worked nicely on my Sony Xperia S (aka Lt26i) on stock rom, with init.d support (Universal init.d support)
:good:

Hi there. I wonder if it's possible to disable GPU rendering in lollipop. My phone is still using gpu to draw the UI even after I uncheck 'disable HW overlays' from developer options. I am having lag issues while playing games. I think it's because System UI is always using GPU and as a result my games are laggy, but those same games work perfectly fine on kitkat without any lags.
I can see GPU usage curve spiking from 40% to 80% all the time in system monitor.

shaktishekhar said:
View attachment 2741805
Script To Make Disable Hardware Overlays Permanently On Boot use the script using init.d or script manager or boot shell :laugh:
Code:
#!/system/bin/sh
(while :
do
sf=$(service list | grep -c "SurfaceFlinger")
if [ $sf -eq 1 ]
then
service call SurfaceFlinger 1008 i32 1
break
else
sleep 2
fi
done
) &
Click to expand...
Click to collapse
Thanks for script works on CM12,1

Underground_XI said:
What is the purpose/benefit of these options?
Click to expand...
Click to collapse
Don't touch force gpu rendering. But disable hw overlays reduces lags in system animations when u browse your phone. I use this cause I hate animations lag. But note that when enabled it'll cause little lag in gaming.. so it's your choice.

shaktishekhar said:
View attachment 2741805
Script To Make Disable Hardware Overlays Permanently On Boot use the script using init.d or script manager or boot shell :laugh:
Code:
#!/system/bin/sh
(while :
do
sf=$(service list | grep -c "SurfaceFlinger")
if [ $sf -eq 1 ]
then
service call SurfaceFlinger 1008 i32 1
break
else
sleep 2
fi
done
) &
Click to expand...
Click to collapse
Genius.

[TUTE][TIPS] Android RAM Management

Android RAM Management
What's this thread about?
This is a brief account of some useful aspects of android memory management and what could be done to make it better or to suit our needs. This is arranged in two parts; A) RAM Management Lesson. B) RAM Management Tips. Whoever is familiar with the Android RAM management concepts can skip to the second part (2nd post). [highlight]Please read and understand carefully before applying anything to the phone. I'm not responsible for any unwanted effects thereby. Credits belong to respective authors of any MOD/APP discussed here.[/highlight]
A) RAM Management Lesson
Android uses a different way of handling processes. Instead of killing every process after its activity ended, processes are kept until the system needs more memory. The idea is to give speed improvements if you start that activity again. But how/when does Android kill a process if it needs more memory and and which process to kill first?
This is managed by the LMK (Low Memory Killer) driver of Android. You may already know that every app/process in Android is assigned an oom_adj value, which indicates the likelihood of it being killed when an out of memory (OOM) situation occurs. More higher it's value, the higher likelihood of it getting killed. Valid range is -17 to +15. (if in the -17 range means it won't get killed). According to that, there are six groups (OOM groups), into which apps/processes are categorised:
1. Foreground app
2. Visible app
3. Secondary server
4. Hidden app
5. Content provider
6. Empty app
Basically these could be described as..
FOREGROUND_APP:
// This is the process running the current foreground app. We'd really
// rather not kill it!
VISIBLE_APP:
// This is a process only hosting activities that are visible to the
// user, so we'd prefer they don't disappear.
SECONDARY_SERVER:
// This is a process holding a secondary server -- killing it will not
// have much of an impact as far as the user is concerned.
HIDDEN_APP:
// This is a process only hosting activities that are not visible,
// so it can be killed without any disruption.
CONTENT_PROVIDER:
// This is a process with a content provider that does not have any clients
// attached to it. If it did have any clients, its adjustment would be the
// one for the highest-priority of those processes.
EMPTY_APP:
// This is a process without anything currently running in it. Definitely
// the first to go!
Click to expand...
Click to collapse
These groups are defined by oom_adj value limits, and apps would fall into one of those groups according to the oom_adj value assigned to that particular app. "Foreground apps" usually have an oom_adj value of 0 or less (so they are the least killable; i.e High priority). "Empty apps" have a higher oom_adj (they are killed early; i.e Low priority). Also, oom_adj value changes according to the state of the user app; it's 0 when the app is active in the foreground and assigned a higher value when the app goes to the background.
Why their "killability" differ? Apps belonging to these different groups (that have different oom_adj's), start to get killed at different levels of free RAM. These triggering RAM limits are defined by the LMK minfree values. Above 6 categories correspond with 6 RAM limits which are set in the LMK minfree. Eg: Stock Android 4.3 in our SP comes with the minfree values of 58,68,78,88,98,118. (these are in MB; see below how to check it). Practically what it means is, Empty apps will get killed when ram goes below 118mb, Content providers when it goes below 98mb, Hidden apps when it goes below 88mb and so on.. lastly starts killing Foreground apps when ram goes below 58mb. You may notice that this last value (58mb) is not desirable when using memory intensive apps like heavy games. The app might shutdown while we interact with it. It won't be a surprise if RealRacing3 would shutdown in the middle of a race with these minfree settings!
[Highlight]Notes:[/highlight]
1. In our SP (and newer kernels), oom_[highlight]score[/highlight]_adj is used instead of old oom_adj. (oom_score_adj valid range is -1000 to 1000). But oom_adj is also maintained for compatibility I think.
2. It is said that there are many OOM process categories that are assigned different oom_adj priorities by the ActivityManagerService, but eventually all of those would be considered under above six slots/groups (according to oom_limits), for the purpose of killing by the LMK minfree triggers. Therefore, those six are the importatnt ones for normal users like us.
[highlight]Now, to the practically important part...[/highlight]
# We can check the minfree values (also change them) and see the OOM groupings of apps/processes with this Memory Manager app easily.
a) LMK Minfrees:................... ......................................b) OOM groupings:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
....
If we click on an app in the list and select 'more info', we can see it's oom_adj value. In my case, System UI has -12 (foreground), Home Launcher has 1 (visible group) etc..
# We can check these manually in a terminal too..
a) LMK Minfrees:
Give the following command (without quotes) in a terminal emulator or adb shell: "cat /sys/module/lowmemorykiller/parameters/minfree"
Code:
$ cat /sys/module/lowmemorykiller/parameters/minfree
[b]15000,17532,20065,22598,25131,30263[/b]
** These are in pages; 1 page=4K. Therefore, converting these in to MB results in.. 58,68,78,88,98,118. (e.g: 15000 x 4 /1024 = 58,5938)
b) OOM_adj value of an app:
*This is not much useful. But nice to know where to get these values from.
E.g. take home launcher. Find out it's PID (process ID) like this.. (command with output posted)
Code:
$ ps |grep [b]home[/b]
u0_a26 1653 721 471408 78076 ffffffff 00000000 S com.sonyericsson.home
It's pid is 1653. To see it's oom_adj value..
Code:
$ cat /proc/[b]1653[/b]/oom_adj
1
It's 1 (foreground). You might get 6 (hidden). So, your home is easily killed than my home . See below why..
At the same time we can see the new oom_score_adj..
Code:
$ cat /proc/[b]1653[/b]/oom_score_adj
58
* To convert old oom_adj value to newer oom_score_adj..
oom_score_adj = (oom_adj x 1000)/17 (truncate the decimals). So, (1x1000)/17=58.823
*There's another value (0-1000) of oom_score (cat /proc/1653/oom_score), which is THE actual indicator of how likely a process will get killed. It changes according to the tunable oom_score_adj and other factors..? something like that.. forget it!
[highlight]## The above mechanism could also be described according to what is mentioned in kernel source files[/highlight], as below. Can skip if it's boring ..
It's from 'drivers/misc/lowmemorykiller.c' of kernel sources (4.3; .266)
* The lowmemorykiller driver lets user-space specify a set of memory thresholds
* where processes with a range of oom_score_adj values will get killed. Specify
* the minimum oom_score_adj values in
* /sys/module/lowmemorykiller/parameters/adj and the number of free pages in
* /sys/module/lowmemorykiller/parameters/minfree. Both files take a comma
* separated list of numbers in ascending order.
*
* [highlight]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_score_adj value of 8 or higher when the free memory
* drops below 4096 pages and kill processes with a oom_score_adj value of 0 or
* higher when the free memory drops below 1024 pages.[/highlight]
*
* The driver considers memory used for caches to be free, but if a large
* percentage of the cached memory is locked this can be very inaccurate
* and processes may not get killed until the normal oom killer is triggered.
Click to expand...
Click to collapse
If we take our phone values, "cat /sys/module/lowmemorykiller/parameters/adj" command returns: "0,58,117,235,529,1000". These are in (new) oom_score_adj values. If we convert them to (old) oom_adj values, these become "0,1,2,4,9,15". (eg:117x17/1000=1.989=2; The last value becomes 17, but oom_adj range ends with 15, so we take 15). Now, with our minfrees of 58,68,78,88,98,118, what it means practically is to kill processes with a oom_adj value of 0 or higher when the free memory drops below 58mb and kill processes with a oom_adj value of 1 or higher when the free memory drops below 68mb and so on... Therefore, it's clear that the adj values "0,1,2,4,9,15" (or score_adj values "0,58,117,235,529,1000") define the limits of each of 6 OOM slot described above.
Another point to note is what mentioned above in the kernel source file "..driver considers memory used for caches to be free..", which is described below.
[highlight]What is "Free RAM"?[/highlight]
What's reported in many apps as "free ram" is actually not free/empty. Linux/Android always tries to utilise the whole ram in some way, so the ram is not wasted. Ram which is not used by active apps, is used for caching apps and for some buffers. These caches and buffers can release memory for apps when needed. We can see the ram usage in detail with this command.. "cat /proc/meminfo" [giving "watch cat /proc/meminfo" would refresh the output every 2 seconds].
Code:
$ cat /proc/meminfo
MemTotal: 859764 kB
[B]MemFree: 26380 kB
Buffers: 2008 kB
Cached: 136600 kB[/b]
SwapCached: 0 kB
Active: 557312 kB
Inactive: 70520 kB
...blah.. ..blah...
....
Reported "free ram" was ~150mb when this was taken. Out of that, most (135mb) is already cached. ["Free RAM"=MemFree+Cached]. Actual free is very little. So, increasing "free ram" makes the phone much snappier because most of that "free" part of the RAM is used for caching things.
-->> RAM Management Tips

B) Tips for better RAM management.
Following is an account of which i benefitted from, sharing for others who may not be aware of these. Your milage may vary... Desired "RAM Management" differs depending on whether expecting more multitasking or a snappy phone with lot of free RAM. Nowadays, phones with better specs generally won't show any lag even if tuned for multi-tasking , although "free RAM" stays little lower. I prefer towards more multi-tasking
1. Change the minfree values to suit your needs. [highlight](Need Root access)[/highlight].
LMK Minfree values can be changed on the fly. Use lower values if you want more multitasking. Higher values if need more "free ram" for gaming etc.. . I use 8,12,45,65,95,165 for more multitasking and for foreground apps to stay until ram becomes much lower. Asphalt8 never crashed with this! If we use values like 15,25,95,145,195,245 "free ram" would be more but background apps (e.g. Hidden apps) would shutdown earlier. However, make sure NOT to increase the first 2 slots too high, so that the Foreground and Visible apps would stay even if RAM goes lower.
How to set/change them:
a) You can set those values with the above Memory Manager app and press Apply. (and tick 'apply at boot' for those values to be applied at every boot).
** There are many preset values you can experiment with.
b) Or can do the manual way.. Give the following command in a terminal/ADB shell:
Code:
echo "2048,3072,11520,16640,24320,42240" > /sys/module/lowmemorykiller/parameters/minfree
(That's after "su" command to get root prompt). ** Need to 'echo' them in pages; not in MBs. See first post how to convert them.
Note: This won't survive reboot. You can run this command as a script with init.d every boot. (For init.d support, check this). The script would look like this:
Code:
#!/system/bin/sh
echo "2048,3072,11520,16640,24320,42240" > /sys/module/lowmemorykiller/parameters/minfree ;
c) Can use Minfree Manager app. To set the minfrees, press Apply after entering the values. If we press 'Apply at Boot', it saves a script under init.d. No hassle.
** There are many apps that can do these kind of changes. Eg: Auto Memory Manager, Ram Manager(Free/Pro)-with other options. The above described ones are very easy to use.
2. Use 'App Settings' xposed module to make any app "stay" in memory (make it "Resident"). [highlight](Need Root access)[/highlight]
It would definitely help multitasking by keeping the needed apps in the background without getting killed, even if RAM becomes low. It possibly works by reduces the app's oom_adj value. That's why you can see Opera Mini in the 'Foreground app' list in my screenshot above (1st post). It's oom_adj value is 0. You can do this for your home launcher and any app you wan't to stay un-killed in the background.
Caution: Making apps to stay in memory would make them stay without being killed, even when e.g. a heavy game is starving for RAM. Therefore, indiscriminate use of this option is not advised. I think it's better to..
(i) Apply only to the apps which have an 'Exit' button/menu, so we can shut it down when needed.
(ii) If no exit button, Add to the 'Greenify' list to be hibernated when the app is not needed. But it asks for confirmation before hibernating these kind of apps with 'High Priority' oom_adj status.
How-to:
1. Get Xposed installer from here. Install it. Install the Xposed framework through it. Refer to the respective thread for more details.
2. Then download the 'App Settings' module through Xposed installer..
3. Open 'App Settings'.. App list will load.
4. Select the app you wan't to tweak.. It will lead to a page as seen in the screenshot above.
5. Select 'Resident' and save (upper right corner button). Can change any other setting if needed.
3. Use zeppelinrox's jar patcher tools to patch services.jar. [highlight](Need Root access)[/highlight].
It changes Home Launcher priority and many other LMK related tweaks. This is why you see my home launcher is under visible apps (oom_adj 1). No launcher redraws even after asphalt8! See the particular thread for details. In summary, patching services.jar results in (quoted from the thread):
- This will SuperCharge Your Home Launcher and ADJ/OOM Priorities! You pick launcher strength!
- This lets you run up to 70 hidden apps instead of the default 15 (RAM permitting) without breaking the lowmemorykiller!
- This tries to bypass the 30 minute service inactivity limit by increasing it to 24 hours.
Click to expand...
Click to collapse
** From ICS up, Android doesn't read ADJ values from build.prop or local.prop - they are hardcoded into services.jar! That is the reason for needing to patch services.jar to change OOM priorities. More details in the respective threads.
How-to (quoted):
Get Jar patcher tools from the thread. I used 'Ultimatic_Jar_Patcher_Tools_RC7_TEST6_ALL_DEX_ALL_OSes_NO_FLASH.zip'. Extract it in the PC. Make sure ADB drivers installed.
How to run -=Ultimatic Jar Patcher Tools=-
1. Connect your Android to your PC with Android Debugging ENABLED and Mass Storage DISABLED so your device has access to your sdcard.
2. Windows: Run either the zip's *.bat or the attached *.exe
If running the exe, you can put a different ultimate jar power tools script version in the same folder and it will use that one otherwise it uses the embedded version!
If you have cygwin installed, you can even use the zip's *.sh file at the cygwin prompt.
Linux/Mac OSX: run the zip's *.sh file
Just be sure to read everything and answer Yes or No as is your preference.
Example: The script allows you to choose the level of your Launcher's Super Strength! (BulletProof, Die-Hard, or Hard To Kill)
Click to expand...
Click to collapse
** Always keep a cwm backup before attempting this; might not get it correct in the first attempt..
4. With the above jar patching, can use zeppelinrox's supercharger script. [highlight](Need Root access)[/highlight].
It can be used to change the minfrees and it re-groups the OOM categories. It also has tons of other cool tweaks. If we check "cat /sys/module/lowmemorykiller/parameters/adj" after applying the SuperCharger scripts to our phone, it returns.. "0,176,352,588,705,1000". Converting to oom_adj values (see 1st post) it becomes "0,3,6,10,12,15". Comparing with stock values (0,1,2,4,9,15), we can see that the above described six OOM slots are re-arranged, sort-of categorising more processes towards higher priority. Can test those settings by echoing those values (this won't survive reboot):
Code:
echo "0,176,352,588,705,1000" > /sys/module/lowmemorykiller/parameters/adj
** Not advisable to meddle with this if no clear idea about what is being done. Use the SuperCharger script instead. Checkout the respective thread for more info.
[For me, this OOM regrouping made some task killings more difficult and it didn't relese RAM readily when needed for heavy games..(may not be same for others ). So I'm not using it at the moment. I'm setting up minfrees as described previously.]
How-to (briefly):
1) Get the latest SuperCharger script from the thread.
2) Make sure requirements are met. Eg: Rooted, Busybox installed.
3) Run the script through 'Script Manager-Smanager' app (with root access granted).
4) Read the output of the screen and reply to the prompts accordingly.
** Keep a cwm backup before attempting this, just in case..
5. Override the "Hidden app limit" of Android. [highlight](Need Root access)[/highlight].
In addition to the LMK driver mechanism described above, this is another parameter that leads to killing of Hidden and Empty apps. Apps are killed when the number of those apps go beyond the specified limits. (Traditionally it was 15, so no more than 15 hidden apps would stay in the background even if there's plenty of RAM). There's a build.prop setting which can control this in our SP. (Btw, services.jar patching mentioned above makes that limit to 70). With the build.prop setting mentioned, we could make it to even 150 ! (This way, we can maximize multitasking and app killing is fully handed over to LMK minfrees, which we can control).
How-to:
Code:
ro.sys.fw.bg_apps_limit=70
Add this line to end of build.prop file (in /system) and leave another blank line below that, and save the file. Then reboot.
Tip: Build Prop Editor is an easy way to edit the build.prop.
** Always keep cwm backups before doing these kind of things.
How to test:
a) Install CatLog app (need root) [This is for reading Logcat]
b) Run it and enter "longer" (without quotes) in the filter bar. Might get a filtered output like this:
It means that the 24th Empty app had got killed, because of exceeding the hidden app limit. This is after services.jar patching making the Hidden app limit to 70. Before it was #17 if I remember correctly.
c) Check the same output after applying the build.prop setting. Should get a little increase. (When I made Hidden app limit to 100, output was #34th empty app gets killed. So, I wen't upto 150 until that kind of output disappeared ).
## Credits to @zeppelinrox for finding that build.prop setting. You can read what happened here in his thread.
How it works:
By @zeppelinrox
In Android 4.2 the max hidden apps are divided into 2 parts (In AMS smali the value is stored in "mProcessLimit")
Part of it goes towards hidden apps.
Part of it goes towards empty apps.
So what happens is it gets the max apps limit (v2)
It gets multiplied by 2 so "v2" is doubled in value.
Now... that is divided by 3 and that value is assigned to empty apps (v13)
Finally, empty apps (v13) is subtracted from v2 to give you hidden apps (v17)
So by default, there are MORE empty apps than hidden apps!
2/3 are empty
1/3 are hidden
So your original config was probably...
max hidden apps = 25
empty apps = 17 (25x2/3)
hidden apps = 8 (25-17)
So normally (without jar patching), if the limit is 70 it would break down like this...
max hidden apps = 70
empty apps = 46 (70x2/3)
hidden apps = 24 (70-46)
** Services.jar patching reverses this ratio (to give more allowance to Hidden apps than Empty apps. Then it results in:
max hidden apps = 70
empty apps = [highlight]23[/highlight] (70x3/9)
hidden apps = 47 (70-23)
Click to expand...
Click to collapse
That's why my 24th Empty app was getting killed with app limit of 70. You might get a totally different value if this build.prop setting is applied without services.jar patching. Appreciate your feedback
[highlight]** Please Note: I'm no dev. I wrote this according to what i understood by reading around in the net. I'd be more than glad if anyone points out any shortcomings/improvements. Thanks.[/highlight]
Credits/Sources
@zeppelinrox for his supercharger thread with overwhelming info, for finding out the build.prop setting in our SP, for explaining things and many more!
@androcheck for his thread
Took more info from here, here, here, and here.

[Highlight]An interesting observation...[/highlight]
Many of us refer to 'Settings>Apps>Running' to see how much free RAM is available at a particular moment. Generally we believed that it shows the correct value. But, some observations makes that value doubtful. E.g: This value doesn't tally with /proc/meminfo values. Furthermore, 'Free RAM' indicated by other apps at times are totally different.
(1).CoolTool - 121 MB
(2).meminfo (watch cat /proc/meminfo) - Looks compatible with cooltool value.
(3). Android says - 23MB!!??
**(all 3 values were updating realtime..)
Sometimes it goes the other way:
(gave time to settle down of course)
Any thoughts?? Does anyone experience like this or only me?

Just in case..

mrhnet said:
@androcheck for his thread...
Click to expand...
Click to collapse
Hi @mrhnet: I got pinged by your mention of my username. Thank you for this valuable thread! It's so important for xda having people around which actually explain and give knowledge to others! This is how a community should work! Great work! :good:
P.S.: Also thanks for giving me credit. That's not to be taken for granted. When I search the web for the unfortunate typo in my posting "on Android the current forefround application" I find a lot of resources which simply copied my words and often did not give any credit. So I appreciate this very much!

@androcheck
Thanks for the encouragement..

nice tutorial with full descriptions...great..:good:

This is wonderfull! I will add this to the tutorial Index this weekend

mrjraider said:
This is wonderfull! I will add this to the tutorial Index this weekend
Click to expand...
Click to collapse
Thanks. That's nice of you

thx u very much for the detailed explanation, gonna try ur recommended values later

great bro can be a sticky thread

mrhnet said:
Just in case..
Click to expand...
Click to collapse
Nice thread dude.
Now I'm glad that I had patience with your patching issues lol
However I don't think I have the patience to go into every tiny detail which is why I link to @androcheck 's thread in my original Supercharger OP (which is now post #3)
And you may find useful the new tool that I'm finally on the verge of releasing...
androcheck said:
Hi @mrhnet: I got pinged by your mention of my username. Thank you for this valuable thread! It's so important for xda having people around which actually explain and give knowledge to others! This is how a community should work! Great work! :good:
P.S.: Also thanks for giving me credit. That's not to be taken for granted. When I search the web for the unfortunate typo in my posting "on Android the current forefround application" I find a lot of resources which simply copied my words and often did not give any credit. So I appreciate this very much!
Click to expand...
Click to collapse
Yeah don't you hate that... personally I'm to lazy to copy other people's efforts and rather link to them while doing something new.
No sense in retreading a good tire

zeppelinrox said:
Yeah don't you hate that... personally I'm to lazy to copy other people's efforts and rather link to them while doing something new.
No sense in retreading a good tire
Click to expand...
Click to collapse
Thanks.
I didn't take any offense, if not I would have written it, someone else would have. In the end the knowledge has spread.

@zeppelinrox
I'm so glad about your comments on this thread. Thanks
Awaiting for your new works.. as always..

mrhnet said:
@zeppelinrox
I'm so glad about your comments on this thread. Thanks
Awaiting for your new works.. as always..
Click to expand...
Click to collapse
Soon.
It's done but gotta write up an OP
Edit: Done http://goo.gl/9H58pS

This is a great thread, you've explained everything very well. :good:
In my experience, RAM management works best if I set very low LMK values, like this. Anything higher means processes will get closed sooner.
Multitasking is good with this, not very good, though, because this is a Sony ROM, but still way better than higher values.
But be warned, using these values on stock 4.3 made it unstable for me, but it works on stock 4.1 without any problems.
Also, I've read on some sites that Sony will release Kitkat for the SP in June, and Kitkat has ZRAM enabled and also some other memory management-helping changes are made by Google. So I really hope it will be released for our device.
Edit (05.23): Well, it seems after a few days of testing, that these low values don't do anything good. The phone slows down a lot. So, this post might be considered pointless. Anyway, it was a good experiment.

I found one thing: in /proc/meminfo it shows more than 200 MB at Cached, but the launcher still redraws when i press Home in Chrome, and sometimes when going back from minfree manager (while chrome is running). So why doesn't the system utilize the Cached memory instead? I see that you, mrhnet, have 78 MB cached on one of the screenshots... Is this some sort of ram management bug in the stock 4.1 or what?

Lajbymester said:
I found one thing: in /proc/meminfo it shows more than 200 MB at Cached, but the launcher still redraws when i press Home in Chrome, and sometimes when going back from minfree manager (while chrome is running). So why doesn't the system utilize the Cached memory instead? I see that you, mrhnet, have 78 MB cached on one of the screenshots... Is this some sort of ram management bug in the stock 4.1 or what?
Click to expand...
Click to collapse
200mb cached means it's included in "free RAM". But it changes according to RAM demand/usage by apps. (Give "watch cat /proc/meminfo" command [without quotes] in a terminal to see; "watch" command runs what comes after that every 2 seconds). Maybe, by the time you switch from Chrome to terminal, Cached amount might have changed. (I think Chrome is a memory hog btw; haven't used it much).
If you really want to see what was in meminfo while chrome is on, I suggest to "record" meminfo values to a file real-time. Can do like this:
*Open terminal emulator
*go to /sdcard
Code:
cd sdcard
*append output of meminfo to a file every 2 seconds
Code:
watch cat /proc/meminfo >> memlog.txt
*leave terminal emulator in background and do whatever in chrome. Meminfo values should be recording in the background; terminal is not easily shutdown because it has a notification (apps having a notification saying that it's running has a high priority I think).
*then come back to terminal emulator and do a "ctrl+c" to break the recording (see terminal settings to know what's assigned as ctrl button)
*now you have a memlog.txt file in sdcard with meminfo output every 2 seconds (might look overwhelming ). If 2 seconds is too frequent, can adjust "watch" command accordingly (eg: watch -n 10 cat /proc/meminfo). Just give "watch" command to see it's usage.
You can go through that file leisurely to see how Cached etc have changed with time. Can filter with "grep" to avoid other gibberish.
Eg:
Code:
grep -w Cached: memlog.txt
This command outputs only the "Cached:" line in the file. [Remember: everything is case sensitive in Linux]. You can even write that output to another file for ease (can do for other values also):
Code:
grep -w Cached: memlog.txt >> Cached.txt
grep -w MemFree: memlog.txt >> MemFree.txt
grep -w Buffers: memlog.txt >> Buffers.txt
Then can go through these files leisurely to see min/max values. I think you can do lot of things with "grep". A Linux geek might even arrange these data to make a graph! @zeppelinrox is the man for this I think

Thanks for the very detailed reply
Actually I was doing the "cat /proc/meminfo" command on the computer using adb on the computer, so switching apps wouldn't interfere. ("watch cat /proc/meminfo" doesn't work for some reason, it doesn't output anything but the actual date). And while looking at Chrome with 2 heavy desktop websites, it was showing ~220 MB at Cached. It doesn't ever go below 180 MB...

Ok.
Dunno exactly what's wrong there.. Just remembered a part from kernel sources I've mentioned in OP:
The driver considers memory used for caches to be free, but if a large
* percentage of the cached memory is locked this can be very inaccurate...
Click to expand...
Click to collapse
Maybe part of Cached is "locked"?? Can do a reboot and see whether the situation persists (if not done already).