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