• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Android's built-in low memory taskkiller

FatDroid

Lurker
Jan 29, 2010
6
0
Androcheck over at xda figured how to configure Android's built-in taskkiller that works based on available RAM.

How to configure Android's *internal* taskkiller - xda-developers

I know this forum likes to believe that Linux is some magic OS that was designed purposely for multitasking in limited RAM situations. But, give it a try. I found it to make a significant difference -- more than switching to MDC did. To test the change, login in to your rooted phone and run:

Code:
echo "1536,2048,4096,15120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree

If this makes your phone faster, than you can make the change permanently by adding that line to one of the init scripts. I'm using MDC, and so I added it to /system/init.d/compcache.sh.

What this does is to make the taskkiller start killing off tasks more agressively to free up more RAM. The line is different from the default value in the last 3 values. These correspond to being more aggressive on background apps, unused providers, and empty apps. Read the XDA posts to get more information.
 
This may cause problems just like the auto-task-killers as it could kill messages, clock, and so on depending on what was using the RAM. RAM is generally not the cause of slowdowns. Killing apps based on memory seems to help but what you are really doing is killing apps that are taking up the CPU. I wouldn't set the auto kill very aggressive at all. I haven't used a task killer since I got a set of apps I like and my phone is snappy, has good battery life, and the only time it gets rebooted is when I forget to charge it.

While I can understand people wanting to kill tasks I assure it it's not necessary unless you have an app that isn't coded properly. Background tasks aren't actively using memory. What there is of them in memory is swapped in and out as needed. Unless a program is actively running it won't slow down your phone. Using the task manager in ES File Explorer shows what the status of your running apps is. If it says background it's not slowing your phone down. Memory management on Linux is nothing at all like memory management on Windows and the same rules do not apply and in some cases are contra-indicated.

The other issue I see with this battery life. If you make this more aggressive it will check more frequently using more partial awake time at the very least. It will use CPU time to figure out what to kill. It will kill things that auto-restart and their auto-restart uses more battery to restart than it does to leave them sleeping.

The XDA guys are amazing and there is no doubt about that at all and I am very impressed that they found this. I am very impressed at all of the ROMs as well. As amazing as these guys are they have been hacking Windows devices for years and I see a lot of assumptions made that stem directly from that and not applicable to the Android platform. With a hack like this I wouldn't recommend doing it to your phone unless you have an understanding of the underlying OS and can tell when what you are doing messes up your phone. This is not the same as optimizing apps or creating skins. Root access can be a dangerous thing and you can actually screw your phone up really badly if you don't know what you are doing. I wouldn't play with stuff like this unless you know something about Linux, memory management, and the Android system to begin with. It's not a good starting point for learning those things.

That said I am going to go play with this a little bit now and try to figure out how it decides what apps to kill and if it will kill essential services. Because it's automated I am curious to see how it decides what to kill. Messages and clock may be automatically excluded because they are system service but Sense isn't. And yeah I am mostly not taking my advice because I am a huge nerd and like to live on the edge but that's with the caveat that I do know a lot more than the average user and have a damn good understanding of Linux going. :p
 
Upvote 0
Agreed, make sure you do a nandroid before effing with any of your startup scripts!

I know I ranted a bit there...sorry :) my point was short: You can mess up your phone, turn it into a brick, and screw yourself playing with things at this level. Thanks for making it understandable after I got down off my soapbox!

Here is some more literature to read:

An Architect's View: LowMemoryKiller in Android

Taming the OOM killer [LWN.net]

So, it looks like it uses a set of parameters in OOM_ADJ to determine which processes to kill. Processes are given a OOM score which helps determine which processes to kill when the time comes.

Great resource. I know what I'll be doing while I avoid doing real work today. :)
 
Upvote 0
This may cause problems just like the auto-task-killers as it could kill messages, clock, and so on depending on what was using the RAM. RAM is generally not the cause of slowdowns. Killing apps based on memory seems to help but what you are really doing is killing apps that are taking up the CPU.

While I can understand people wanting to kill tasks I assure it it's not necessary unless you have an app that isn't coded properly. Background tasks aren't actively using memory. What there is of them in memory is swapped in and out as needed. Unless a program is actively running it won't slow down your phone. Using the task manager in ES File Explorer shows what the status of your running apps is. If it says background it's not slowing your phone down. Memory management on Linux is nothing at all like memory management on Windows and the same rules do not apply and in some cases are contra-indicated.

You are obviously trying to be helpful, but please go learn more about operating systems before reciting half truths and false claims. It's quite annoying. There is no swapping on Hero, since there is no swap (by default at least). Lack of cache can slow down the system, especially since it doesn't seem like the flash in a Hero is that fast. The Background OOM_ADJ is not based on whether the application is consuming CPU cycles, it's based on application visibility.

Lastly, yes this taskkiller does kill the clock and messages apps. No, this does not affect receiving messages and alarms. My guess why this is that this taskkiller kills tasks in a different way than all the 3rd party taskkillers. For alarms, this could be because the app registered itself with android.app.AlarmManager only when the app is told to close by the internal task manager. I'm not sure how this works with messages.

Maybe someone who has time can look at lowmemorykiller.c, figure out how it kills apps and replicate that in other taskkillers to achieve the same benefit.

<shrug>
 
Upvote 0
You are obviously trying to be helpful, but please go learn more about operating systems before reciting half truths and false claims. It's quite annoying. There is no swapping on Hero, since there is no swap (by default at least). Lack of cache can slow down the system, especially since it doesn't seem like the flash in a Hero is that fast. The Background OOM_ADJ is not based on whether the application is consuming CPU cycles, it's based on application visibility.
I do this for a living. I don't need to go learn more. You don't refute a single thing I said and claim I am reciting half truths and false claims. You don't offer anything other than an accusation with no evidence to back up your claims. I clearly state that I haven't messed with this and would be looking into it. My statements are based on what I already know, "doing" Linux for a living for better than a decade at this point. Cache != RAM and swap =! cache. Swap is only necessary when the RAM isn't enough to handle the application load. My workstation has no swap at all and runs absolutely perfectly. Of course it has 32GB RAM but that is beside the point as desktops are not the same as phones.

So lets get technical here, since you implied I don't know what I am talking about, and get into the nuts and bolts of OOM_ADJ...shall we? First off you are wrong. Dead wrong. OOM_ADJ doesn't work on visibility at all. It works off a score calculated by multiple factors including: amount of memory used, CPU time, length of time the PID has been running, nice and more. On Android it works differently than in the standard kernel, and this is the part I didn't know and the explanation to your next paragraph, it doesn't actually kill the processes outright but rather saves their state and then kills them. The trade off is latency switching between applications as they have to reload, which does affect the CPU and therefore the battery. And if further pressure is added, which this hack will do, it kills the processes which have had their state saved. So the first round of low memory freeing saves state and the next level kills things. So it will eventually, if you set the thresholds low enough affect receiving messages and such if it kills those processes and it will increase latency overall as the processes with saved states have to reload. In other words it won't increase your performance all that much if you tweak the settings. You could have found all of this information in the first result on Google if you had bothered to look. I admit my initial response was based on the standard kernel and not the changes that the Android devs made but my advice remains the same.

OOM killer is turned off in all major Linux distros. The Android dev team made some changes and turned it back on. With low enough thresholds it will make any system unstable and your phone is no exception. So unless you know what the hell you are doing this is not a setting you should be messing with. Since you don't even know what it bases it's score on (visibility, really?) I would say you shouldn't be screwing with it. It's certainly not beginner stuff, not even beginner rooting stuff. Having read up, after I posted, I understand much more than I do now. I don't know that I agree with the devs turning it on to begin with, which is the subject of controversy in and of itself, but I do know without a doubt that it something beginners shouldn't be playing with.

Lastly, yes this taskkiller does kill the clock and messages apps. No, this does not affect receiving messages and alarms. My guess why this is that this taskkiller kills tasks in a different way than all the 3rd party taskkillers. For alarms, this could be because the app registered itself with android.app.AlarmManager only when the app is told to close by the internal task manager. I'm not sure how this works with messages.

Maybe someone who has time can look at lowmemorykiller.c, figure out how it kills apps and replicate that in other taskkillers to achieve the same benefit.

<shrug>

It doesn't kill apps outright unless the thresholds are met. Set them too low and it will even kill kernel processes. Go read up before you start accusing people who do this crap for a living of speaking half truths and falsehoods. You don't know your arse from a hole in the ground when it comes to OOM_ADJ and you accuse me of reciting half-truths? PUH-LEASE.
 
Upvote 0
Sigh, I was afraid you would do this. First and foremost, keep helping people and take nothing I say as an affront to that effort.

I do this for a living. I don't need to go learn more. You don't refute a single thing I said and claim I am reciting half truths and false claims.

I know you would loose in the credentials game, but I prefer to not to reveal my personal info. So instead, let's go refute more of your points. I already refuted some, but here we go:

romeosidvicious said:
Background tasks aren't actively using memory. What there is of them in memory is swapped in and out as needed.

As I already said, there is no swapping on a Hero, because there is no swap. So all your additional talk about swap is irrelevant.


Cache != RAM and swap =! cache.
No, Linux, Windows, and OS X all use free RAM for cache. You can run top, or task manager, or whatever and see this. The amount of RAM available for cache is reduced when more of that RAM is allocated. As stated above, since there is no swap, all the idle apps are still taking up RAM and hence force cache to become smaller.

OOM_ADJ doesn't work on visibility at all. It works off a score calculated by multiple factors including: amount of memory used, CPU time, length of time the PID has been running, nice and more. On Android it works differently than in the standard kernel, and this is the part I didn't know and the explanation to your next paragraph, it doesn't actually kill the processes outright but rather saves their state and then kills them.
No, OOM_ADJ is set by userspace. You may be trying to describe the overall OOM value. Yes, you don't know how the vanilla Linux, let alone Android works.


So unless you know what the hell you are doing this is not a setting you should be messing with. Since you don't even know what it bases it's score on (visibility, really?) I would say you shouldn't be screwing with it[/QUOTE}
Yes, it is based on visibility. Again, you obviously don't know what OOM_ADJ is for. Taming the OOM killer [LWN.net] It's set in userspace, and in the case of Android, it's set by ActivityManagerService based on visibility. How to configure Android's *internal* taskkiller - xda-developers (first post)

Go read up before you start accusing people who do this crap for a living of speaking half truths and falsehoods. You don't know your arse from a hole in the ground when it comes to OOM_ADJ and you accuse me of reciting half-truths? PUH-LEASE.

Alas, it seems like you're one of those people who know just enough to think they know everything. Anyhow, feel free to go read lowmemorykiller.c (android.git.kernel.org Git - kernel/common.git/blob - drivers/misc/lowmemorykiller.c), and AcitivityManagerService.java (android.git.kernel.org Git - platform/frameworks/base.git/blob - services/java/com/android/server/am/ActivityManagerService.java, especially the computeOomAdjLocked and udpateOomAdjLocked) to prove me wrong. Hell, even just use google.

Anyhow, cheers.
 
Upvote 0
Sigh....I knew it would come to this. Look I don't want to flash my credentials and embarrass anyone but anyways lets move on and talk about how both of you are wrong.

Everyone knows cache is for web browsers and it's a popular way to spell "cash" in England. Basically it's called cache because that's what the web browser uses to "purchase" data from websites. Your computer has to exchange cache for things like pictures and video (a cache exchange is not required for text) That's why if you run out cache you can't visit any more sites.

Swap has nothing to do with computers at all. Why you guys are talking about it is beyond me honestly. Swap is a verb....you "swap" something. You give me your blender and I'll give you my toaster...that's a swap. I suppose you could swap computers.

RAM is a model of truck manufactured by Dodge. As far as I know Dodge has nothing to do with computers. Clearly you both are way off base. How you would even fit a RAM inside a phone is beyond me.

Kernel. Seriously this is out of control - kernels are those little brown things left in the bottom of the popcorn bowl. Kernels don't control anything but yes you can compile them. Often I like to compile a large cup full of them when eating popcorn.

CPU's are the big box that the modem that controls your computer resides in. It's always plugged into a wall so why you guys talk about batteries and cpu's is beyond me.

You guys are clearly amateurs here. Take all your nonsense talk back to the eMachines forum.
 
Upvote 0
Lol
sigh....i knew it would come to this. Look i don't want to flash my credentials and embarrass anyone but anyways lets move on and talk about how both of you are wrong.

Everyone knows cache is for web browsers and it's a popular way to spell "cash" in england. Basically it's called cache because that's what the web browser uses to "purchase" data from websites. Your computer has to exchange cache for things like pictures and video (a cache exchange is not required for text) that's why if you run out cache you can't visit any more sites.

Swap has nothing to do with computers at all. Why you guys are talking about it is beyond me honestly. Swap is a verb....you "swap" something. You give me your blender and i'll give you my toaster...that's a swap. I suppose you could swap computers.

Ram is a model of truck manufactured by dodge. As far as i know dodge has nothing to do with computers. Clearly you both are way off base. How you would even fit a ram inside a phone is beyond me.

Kernel. Seriously this is out of control - kernels are those little brown things left in the bottom of the popcorn bowl. Kernels don't control anything but yes you can compile them. Often i like to compile a large cup full of them when eating popcorn.

Cpu's are the big box that the modem that controls your computer resides in. It's always plugged into a wall so why you guys talk about batteries and cpu's is beyond me.

You guys are clearly amateurs here. Take all your nonsense talk back to the emachines forum.
 
Upvote 0
Sigh....I knew it would come to this. Look I don't want to flash my credentials and embarrass anyone but anyways lets move on and talk about how both of you are wrong.

Everyone knows cache is for web browsers and it's a popular way to spell "cash" in England. Basically it's called cache because that's what the web browser uses to "purchase" data from websites. Your computer has to exchange cache for things like pictures and video (a cache exchange is not required for text) That's why if you run out cache you can't visit any more sites.

Swap has nothing to do with computers at all. Why you guys are talking about it is beyond me honestly. Swap is a verb....you "swap" something. You give me your blender and I'll give you my toaster...that's a swap. I suppose you could swap computers.

RAM is a model of truck manufactured by Dodge. As far as I know Dodge has nothing to do with computers. Clearly you both are way off base. How you would even fit a RAM inside a phone is beyond me.

Kernel. Seriously this is out of control - kernels are those little brown things left in the bottom of the popcorn bowl. Kernels don't control anything but yes you can compile them. Often I like to compile a large cup full of them when eating popcorn.

CPU's are the big box that the modem that controls your computer resides in. It's always plugged into a wall so why you guys talk about batteries and cpu's is beyond me.

You guys are clearly amateurs here. Take all your nonsense talk back to the eMachines forum.


LOL can I give rep for this?
 
Upvote 0
Sigh, I was afraid you would do this. First and foremost, keep helping people and take nothing I say as an affront to that effort.
Let me first apologize. I normally wouldn't do that but I did. No excuse. Re-reading my post this morning I am frankly ashamed of my response. That's what I get for posting after closing down the bar. I am sincerely sorry. It is not my usual response. I enjoy technical conversations and even debates.

I know you would loose in the credentials game, but I prefer to not to reveal my personal info. So instead, let's go refute more of your points. I already refuted some, but here we go:
I doubt I would lose but whether I would is not relevant to the technical details involved and I shouldn't have trotted out my experience.

As I already said, there is no swapping on a Hero, because there is no swap. So all your additional talk about swap is irrelevant.
My talk about swap was showing that it is not always relevant when discussing RAM.

No, Linux, Windows, and OS X all use free RAM for cache. You can run top, or task manager, or whatever and see this. The amount of RAM available for cache is reduced when more of that RAM is allocated. As stated above, since there is no swap, all the idle apps are still taking up RAM and hence force cache to become smaller.
You are right about this but in relation to the way memory management works and its relation to phone speed it is irrelevant.

No, OOM_ADJ is set by userspace. You may be trying to describe the overall OOM value. Yes, you don't know how the vanilla Linux, let alone Android works.
You are wrong here. I posted, albeit in babbling form, the way OOM_ADJ calculates values for deciding what apps to kill. Whether this is set in userspace or elsewhere is irrelevant. It does work differently on standard Linux than on Android because it doesn't do what the Android developers wanted it to do out of the box. They changed the functionality. The description I gave was almost a direct quote from a list of the changes they made to the standard OOM_ADJ.

Yes, it is based on visibility. Again, you obviously don't know what OOM_ADJ is for. Taming the OOM killer [LWN.net] It's set in userspace, and in the case of Android, it's set by ActivityManagerService based on visibility. How to configure Android's *internal* taskkiller - xda-developers (first post)
The process to be killed in an out-of-memory situation is selected based on its badness score. The badness score is reflected in /proc/<pid>/oom_score. This value is determined on the basis that the system loses the minimum amount of work done, recovers a large amount of memory, doesn't kill any innocent process eating tons of memory, and kills the minimum number of processes (if possible limited to one). The badness score is computed using the original memory size of the process, its CPU time (utime + stime), the run time (uptime - start time) and its oom_adj value. The more memory the process uses, the higher the score. The longer a process is alive in the system, the smaller the score.

That's from the first link you posted and it pretty much says the same thing I said but not as drunkenly. What you are describing is a proposed solution to the current way OOM_ADJ works that is used by some developers and directly following that are two other methods in use as well which are also not how Android is doing it. They are using a fifth method (1. The way I described it which is the standard way OOM_ADJ works, the method you described which is in use but by no means a standard, the two other methods mentioned in the article you linked, and the way Android does it which is not the same as any of the others.)

Android handles it is not exacatly how I described it and I will admit that. Again it was likely an artifact of my drunkenness which I apologize for again. Android, unlike the others, has multiple low memory thresholds and acts on them separately. When the first is met, the applications are notified and save their state (I did say that just not correctly) but do not exit this in turn, as I stated, increases latency between applications and is stated in the very article you linked. When the next threshold is met these applications are killed. Which can affect CPU time and therefore battery if they are apps that auto-restart. The next threshold kills active apps. Apparently, although not cited in the article you linked they exempt critical background apps at some point. They way I descried OOM_ADJ does not, in fact apply and neither does the method you cited, the sneaky bastards at Google made up their own method. It may happen in userspace but they use their own heuristics and not any of the other methods mentioned.

Alas, it seems like you're one of those people who know just enough to think they know everything. Anyhow, feel free to go read lowmemorykiller.c (android.git.kernel.org Git - kernel/common.git/blob - drivers/misc/lowmemorykiller.c), and AcitivityManagerService.java (android.git.kernel.org Git - platform/frameworks/base.git/blob - services/java/com/android/server/am/ActivityManagerService.java, especially the computeOomAdjLocked and udpateOomAdjLocked) to prove me wrong. Hell, even just use google.

Anyhow, cheers.
I deserved that snipe. However, using on the sources you cited, I showed we were both wrong. I still stand by my statement that you could bork your phone setting thresholds too low and that this is a setting you shouldn't mess with if you don't know what you are doing. I may not have had the technical details 100% accurate, and believe I stated originally that I didn't know how Android handled it, I am not wrong about this being a dangerous place to be screwing around, which you haven't denied. I was hoping, after showing my arse like I did last night, that I was wrong and I was but the fact remains that your description was also incorrect. Honestly the technical details don't really matter for the point I was trying to make so it doesn't matter who was right. This is a dangerous place to be playing and you could mess up your phone in ways you might not be able to fix if you start mucking around in here.

Thanks for the links but I have a git clone on this machine ;)
 
Upvote 0
Wanted to add some clarification. This is not a setting you want to muck around with manually, due to the risks, if you don't understand the concepts involved. However once the apps that the XDA guys are working on come out it will likely be a different story. If you read the thread over at XDA you'll see the folks experimenting are able to set thresholds that kill services most of us would consider essential. I think once they find optimal settings for the Sprint Hero the apps will be released and it won't be manual mucking around that can make your phone unusable.

Having played with this a little bit so far I am not really seeing much of a performance increase. It seems to be a mixed bag of folks not seeing much and some reporting very snappy performance increases. I think some of the snapiness being reported might be the placebo effect but not having gone very aggressive with my settings I can't say for sure. I am reading the thread over there and going to try some more aggressive settings but it might be a couple of days before I have time to play and actually measure any results.
 
Upvote 0
Folks, all technical sparring aside, what this boils down to is this - it is the real deal. Simply put, root your phone, install one of several custom roms and then head over here [CDMA KERNEL ROM]Gumbo Kernel beta project + RAM hack - xda-developers and read read read. Once you are done reading, download and install the new Kernal and SetCPU. Your phones battery will last a long time and your phone will be noticeably (seriously) faster. I've been running this for over 24 hours now with no ill affects (everything works) and an unbelievable boost in speed.

I have absolutely zero credentials, just a guy who has a Hero and wanted to make it faster. Done.
 
Upvote 0
Folks, all technical sparring aside, what this boils down to is this - it is the real deal. Simply put, root your phone, install one of several custom roms and then head over here [CDMA KERNEL ROM]Gumbo Kernel beta project + RAM hack - xda-developers and read read read. Once you are done reading, download and install the new Kernal and SetCPU. Your phones battery will last a long time and your phone will be noticeably (seriously) faster. I've been running this for over 24 hours now with no ill affects (everything works) and an unbelievable boost in speed.

I have absolutely zero credentials, just a guy who has a Hero and wanted to make it faster. Done.

Ok, did all of this and then did this:

Full thread:

Edit: Oh my....the speed...even dialing someone or getting a call...wow. I'll try if for a few days and see how it goes. So far my stuff is this:

Rooted
Fresh 1.1
GK-0.31-signed.zip
SetCPU (downloaded and installed)
480 max 245 min
 
Upvote 0

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones