Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,786,517 Members 36,759 Now Online
XDA Developers Android and Mobile Development Forum

How to configure Android's *internal* taskkiller

Tip us?
 
androcheck
Old
(Last edited by androcheck; 12th June 2010 at 06:56 AM.) Reason: made link to a real link
#1  
androcheck's Avatar
Senior Member - OP
Thanks Meter 86
Posts: 124
Join Date: Dec 2009
Default How to configure Android's *internal* taskkiller

Hi!

Note:
Sorry this posting got very long. But it will tell you how to configure Android's internal taskkiller which may help getting your hero really speedy again.. Without using any taskkiller.



Here the long story:
I just was curious if already someone tried to play around with Android's internal low-memory task killer.

We all know that 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. These processes usually should not harm the overall performance and should give speed improvements if you start an Activity again. That's the idea.

But when does Android kill a process? And which process? As far as I understood android keeps a LRU (last recently used) list and starts killing the oldest unneeded process. This way it is much smarter than any of the taskkillers we see in the Market.

Just for curiosity I started to investigate how this mechanism works. Please correct me if you think that I got something wrong:


What I found out:
ActivityManagerService.java tracks the "importance" of processes (is foreground, is running a service, ..) and reflects this importance by setting the "oom_adj" value of the process.

(For info: "oom_adj" is a value of every process under Linux which gives the kernel a hint, which process it can kill in an oom [out of memory] situation. You can see this value on every Linux 2.6 system in the proc directory: /proc/[PID]/oom_adj ). The higher this value is set, the more likely this process gets selected by the kernel's oom killer.)

It seems that on Android the current forefround application gets an oom_adj value of 0 and as soon it's not visible anymore it gets some higher value. I assume the concrete value is dependent by the processes' place in the LRU list.


The out-of-memory killer in the standard Linux kernel only runs in one situation: when the available memory is critical low. However in the Android Linux kernel there is implemented a more fine-grained handling of low memory situations.

I found the kernel source file "lowmemorykiller.c" (located in the kernel source tree under "drivers/misc/"; or look here for GIT source tree: http://tinyurl.com/lowmemkiller).


This module seems to be more configurable than the kernel's standard out-of-memory killer as you can define more than one memory limit, when it should get active and you can tell it which oom_adj values it may kill.

In other words:
You can say "if free memory goes below XXXX then kill some process with oom_adj greater then YYY; if free memory goes even more below than ZZZ then start to kill some processes with oom_adj greater than XYXY. and so on.."

So it's possible to define multiple memory criterias and matching processes which can be killed in these situations. Android seems to group running processes into 6 different categories (comments taken out of "ActivityManagerServer.java"):
Code:
FOREGROUND_APP:
    // This is the process running the current foreground app.  We'd really
    // rather not kill it! Value set in system/rootdir/init.rc on startup.

VISIBLE_APP:
    // This is a process only hosting activities that are visible to the
    // user, so we'd prefer they don't disappear. Value set in
    // system/rootdir/init.rc on startup.

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. Value set in
    // system/rootdir/init.rc on startup.

HIDDEN_APP:
    // This is a process only hosting activities that are not visible,
    // so it can be killed without any disruption. Value set in
    // system/rootdir/init.rc on startup.

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! Value set in system/rootdir/init.rc on startup.
    // This value is initalized in the constructor, careful when refering to
    // this static variable externally.
These 6 categories are reflected by 6 memory limits which are configured for the lowmemorykiller in the kernel.

Fortunately, it is possible to configure the lowmemorykiller at runtime!
(But only if you are root). The configuration is set in the file: "/sys/module/lowmemorykiller/parameters/minfree"

So if you want to see the current settings, you can do:

Code:
# cat /sys/module/lowmemorykiller/parameters/minfree
This should produce output like this (or similiar):
Code:
1536,2048,4096,5120,5632,6144
These values are the 6 memory limits on which Anedroid starts to kill processes of one of the 6 categories above. Be careful, the units of these values are pages!! 1 page = 4 kilobyte.

So the example above says that Anddroid starts killing EMPTY_APP processes if available memory goes below 24MB (=6144*4/1024). And it starts to kill unused CONTENT_PROVIDERs if available memory goes below 22MB (=5632*4/1024).


So if you want to try if your Hero goes faster when fewer processes are running you can try to adjust these settings. For example if you practically do not want any empty processes you can set the corresponding value very high. For example, you can set the values like this:

Code:
# echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree
This example will tell Android to kill unused Content providers if less then 60MB is available and kill empty processes if available memory goes below 90MB.

All other processes will stay untouched! Do you see the advantage compared to process killers?


One word about durabilty:
If you change the settings like this, they are NOT PERMANENT. They will be gone after the next restart of your phone. So you can try to play around a little bit. Please share your results if you find some improvements!

To make this settings survive also reboots you need to somehow set this at startup. I am running Modaco's custom rom and added the command to the startup script /system/init.d/ramzswap.sh, but there may be other ways to do this.

Currently I also disabled compcache on my Hero and set the lowmemkiller very aggressive, as it seems to me that this makes my hero very responsive.

So these are my (current) settings:
Code:
echo "1536,3072,4096,21000,23000,25000" > /sys/module/lowmemorykiller/parameters/minfree
(and compcache disabled)

But play around.. I am glad about any feedback.
Please also give feedback if I am wrong or missed something!

Thx!
The Following 56 Users Say Thank You to androcheck For This Useful Post: [ Click to Expand ]
 
felikz
Old
#2  
Senior Member
Thanks Meter 6
Posts: 322
Join Date: Aug 2009
i would be interested in changing the application which is startet when i long press on home (normally its the task changer of sense ui, but i want another program to be started)
schmagmovsquontum
 
awsy44
Old
#3  
awsy44's Avatar
Senior Member
Thanks Meter 21
Posts: 141
Join Date: Jan 2008
Location: Auckland
this is excellent!, I just updated the ramzswap.sh to your settings and I can tell you it does an excellent job so far of running for like 20minutes, my ram is around 76 MB with facebook with all the htc widgets running, it usually drops to around 50 MB, does compcache save alot of ram when you disable it?

Thanks so much for the amazing info!, its hard someone to explain everything for you like you did.
Device :
Samsung Galaxy S III GT-I9300
ROM : CM10.1 (Thanks Codeworkx) 4.2.2
 
inkredi
Old
#4  
inkredi's Avatar
Senior Member
Thanks Meter 5
Posts: 452
Join Date: Dec 2009
Location: Miami
woah!! i cannot stand my phone when RAM is less than 100mb
i keep it around 115~130

anyway whats new in ur method? why not use the Kill-All widgets after setting the ignore list ..or smth like "Automatic Task Killer" ??
HTC Hero > HTC Desire > Samsung Galaxy S2 > iPhone 4S > Samsung Galaxy Nexus > LG Nexus 4 > HTC Ville > Oppo Find 5
 
Branwen
Old
#5  
Senior Member
Thanks Meter 0
Posts: 216
Join Date: May 2009
Location: London
Quote:
Originally Posted by inkredi View Post
anyway whats new in ur method? why not use the Kill-All widgets after setting the ignore list ..or smth like "Automatic Task Killer" ??
Its more sensitive, and doesn't require any more input from the user, whilst having a constant effect
 
androcheck
Old
#6  
androcheck's Avatar
Senior Member - OP
Thanks Meter 86
Posts: 124
Join Date: Dec 2009
The difference of this method compared to task killers like "Automatic Task Killer" is that there is no separate application involved.

There is no widget or taskkiller process which needs to be run.

Instead you configure the Android kernel itself how to handle processes. While taskkillers need to be run regularly (automatically or by hand) to check memory and kill processes, the way I described this gets done complete automatically by the Android kernel, immediately when available memory goes under the configured limits.

There is also no need for ignore-lists or something like this, as the Android kernel knows which applications it can kill and which not. Furthermore you can configure much more fine-grained when to kill which processes and the kernel is using the internal "last recently used" list and kills the least needed processes first.

External task killer only can kill processes "blindly", they cannot see which processes are "empty" (not hosting an Activity) or which have been in the background for the longest time, and so on..


When people tell you that taskkillers are evil, they mean that taskkillers interfere with Androids process management in a way this was never intended. The way I described you still let Android handling processes itself, but you just tell it to be more restrictive.

So this is far less invasive into the Android system and (should ) have less side-effects..

But I'm still learning. I am a programmer who wants to understand things. And fortunately here we have the source to do so..
 
adwinp
Old
#7  
adwinp's Avatar
Senior Member
Thanks Meter 136
Posts: 1,676
Join Date: Jun 2008
Location: urandom
These values can be directly edited in your initrc
*APP_ADJ, *APP_MIN_ADJ, *ADJ, *PROVIDER_MEM, *SERVER_MEM and *APP_MEM
The Following 2 Users Say Thank You to adwinp For This Useful Post: [ Click to Expand ]
 
androcheck
Old
(Last edited by androcheck; 24th January 2010 at 10:27 PM.)
#8  
androcheck's Avatar
Senior Member - OP
Thanks Meter 86
Posts: 124
Join Date: Dec 2009
Thanks for the info!

Hmm.. but how can I change the init.rc? As it is placed directly in the root directory remounting and changing the file seems not to work (like on the the /system partiton).

I can remount and change the file, but the changes are gone after a reboot. The root dir is mounted as "rootfs".. No idea how to change files in there (without building a new ROM).
 
adwinp
Old
#9  
adwinp's Avatar
Senior Member
Thanks Meter 136
Posts: 1,676
Join Date: Jun 2008
Location: urandom
Well, you can extract the initrc from the boot.img (first you need to extract the ramdisk)
Edit, and repack.
The Following User Says Thank You to adwinp For This Useful Post: [ Click to Expand ]
 
intronauta
Old
#10  
Senior Member
Thanks Meter 107
Posts: 280
Join Date: Aug 2009
Very interesting

My minfree: 1536,2048,4096,5120,15360,23040 (compcache disabled)

The system is very fluid and responsive. I dont know if this is by the tweak or compcache, but I see in EStrong Task Manager just the necesary process, no more empty process and more space for hidden process, second.

Very curious.

Tags
guide, how to
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes