Android's built-in low memory taskkiller


Last Updated:

  1. FatDroid

    FatDroid Member This Topic's Starter

    Joined:
    Jan 29, 2010
    Messages:
    6
    Likes Received:
    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 (Text):
    1. 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.
     

    Advertisement
  2. cin925

    cin925 Member

    Joined:
    Nov 20, 2009
    Messages:
    18
    Likes Received:
    0
    Has anyone else here tried this?
     
  3. pdragon

    pdragon Well-Known Member

    Joined:
    Oct 15, 2009
    Messages:
    395
    Likes Received:
    19
    Very interesting find. Thanks for sharing!
     
  4. NCKK

    NCKK Well-Known Member

    Joined:
    Nov 17, 2009
    Messages:
    131
    Likes Received:
    3
    Is this working for the CDMA Hero too? I noticed a majority of these guys were using the Euro Hero.
     
  5. momoceio

    momoceio Well-Known Member

    Joined:
    Dec 14, 2009
    Messages:
    1,235
    Likes Received:
    149
    It's not phone specific...it's an Android thing.
     
  6. chocmatic

    chocmatic Well-Known Member

    Joined:
    Oct 17, 2009
    Messages:
    217
    Likes Received:
    52
    It makes a difference...only thing I can't seem to get to work is to automatically have it run after rebooting phone.
     
  7. momoceio

    momoceio Well-Known Member

    Joined:
    Dec 14, 2009
    Messages:
    1,235
    Likes Received:
    149
    You have to edit one of your init.d startup scripts. Since I'm using Modaco rom...I put it in compcache.sh
     
  8. chocmatic

    chocmatic Well-Known Member

    Joined:
    Oct 17, 2009
    Messages:
    217
    Likes Received:
    52

    Correct....too bad I don't have a init.d directory in the system or system/etc directories
     
  9. romeosidvicious

    romeosidvicious Well-Known Member

    Joined:
    Oct 13, 2009
    Messages:
    270
    Likes Received:
    58
    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
     
  10. momoceio

    momoceio Well-Known Member

    Joined:
    Dec 14, 2009
    Messages:
    1,235
    Likes Received:
    149
    Agreed, make sure you do a nandroid before effing with any of your startup scripts!
     
  11. momoceio

    momoceio Well-Known Member

    Joined:
    Dec 14, 2009
    Messages:
    1,235
    Likes Received:
    149
  12. romeosidvicious

    romeosidvicious Well-Known Member

    Joined:
    Oct 13, 2009
    Messages:
    270
    Likes Received:
    58
    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!

    Great resource. I know what I'll be doing while I avoid doing real work today. :)
     
  13. flammenwurfer

    flammenwurfer Well-Known Member

    Joined:
    Nov 12, 2009
    Messages:
    172
    Likes Received:
    4
    let us know what you find out romeosidvicious. I'm happy with the speed of my Hero as it is, but if this has no ill effects and really increases speed I'll give it a go.
     
  14. chocmatic

    chocmatic Well-Known Member

    Joined:
    Oct 17, 2009
    Messages:
    217
    Likes Received:
    52
    I have already made the changes and so far see no ill effects. I will give it a couple days though
     
  15. FatDroid

    FatDroid Member This Topic's Starter

    Joined:
    Jan 29, 2010
    Messages:
    6
    Likes Received:
    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.

    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>
     
  16. romeosidvicious

    romeosidvicious Well-Known Member

    Joined:
    Oct 13, 2009
    Messages:
    270
    Likes Received:
    58
    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.

    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.
     
  17. FatDroid

    FatDroid Member This Topic's Starter

    Joined:
    Jan 29, 2010
    Messages:
    6
    Likes Received:
    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 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:

    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.


    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.

    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.


     
  18. kennyidaho

    kennyidaho Well-Known Member

    Joined:
    Nov 16, 2009
    Messages:
    416
    Likes Received:
    5
    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.
     
  19. bbv203

    bbv203 Well-Known Member

    Joined:
    Dec 9, 2009
    Messages:
    98
    Likes Received:
    1
    Lol
     
  20. wutwutman

    wutwutman Active Member

    Joined:
    Jan 9, 2010
    Messages:
    36
    Likes Received:
    0
    @kennyidaho

    Priceless LOL +1
     
  21. Twice

    Twice Well-Known Member

    Joined:
    Dec 29, 2009
    Messages:
    53
    Likes Received:
    0

    LOL can I give rep for this?
     
  22. romeosidvicious

    romeosidvicious Well-Known Member

    Joined:
    Oct 13, 2009
    Messages:
    270
    Likes Received:
    58
    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 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.

    My talk about swap was showing that it is not always relevant when discussing RAM.

    You are right about this but in relation to the way memory management works and its relation to phone speed it is irrelevant.

    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.

    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.

    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 ;)
     
  23. romeosidvicious

    romeosidvicious Well-Known Member

    Joined:
    Oct 13, 2009
    Messages:
    270
    Likes Received:
    58
    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.
     
  24. ItsDon

    ItsDon Well-Known Member

    Joined:
    Oct 11, 2009
    Messages:
    77
    Likes Received:
    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.
     
  25. g0tr00t

    g0tr00t Well-Known Member

    Joined:
    Oct 13, 2009
    Messages:
    166
    Likes Received:
    5
    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
     

Share This Page

Loading...