[Xperia SP Q&A, Help & Troubleshooting] mrhnet:
(## This post got longer than I thought.. apologies mate.. :D)

I haven't used Firefox much.. is it a memory hog? I'm assuming you're on stock kernel.

Those output values indicate minfree values of low memory killer (LMK) driver, as you may already know. It's in pages, 1 page=4K, so those values in MB:

58,68,78,88,98,118

These stock rom values don't make much sense.. it means that when "free ram" goes below 58mb, LMK driver should kill the Foreground app, which is in the foreground and which we're interacting with! Why do we need to kill that?? So, these values were causing problems for me (I think ;)) eg. Asphalt8 shutting down in the middle of the game [it's memory intensive, so ram might be going down to that level]. What might be happening in your case is that when using Firefox with many web pages open, if free ram goes quite low, apps might be shutting down. Some techie things about that below.. skip if boring :p

As you may already know, apps/processes in Android are 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, more likelihood of it getting killed. Valid range -17 to +15. (-17 range means it won't get killed). According to that, there are six groups, into which apps/processes will be assigned:

1. Foreground app

2. Visible app

3. Secondary server

4. Hidden app

5. Content provider

6. Empty app

Read details about them here: http://xdaforums.com/showthread.php?t=622666

Foreground apps usually have an oom_adj value of 0 or less, so they are the least killable. Empty apps have a higher oom_adj and they are killed early. Also, oom_adj value changes according to the state of the user app; 0 when it's at foreground and assigned a higher value when the app goes to the background.

Above 6 categories correspond with the 6 memory limits which are set in LMK minfree values.

Practically in your case, Empty apps will get killed when ram goes below 118mb, content providers when 98mb, and so on.. lastly killing foreground apps when ram goes below 58mb. So, what you see being killed belong to one of the groups, which might have got killed accordingly when ram went low.

[Highlight]Note:[/highlight] In our SP (and newer kernels), oom_score_adj is used instead of old oom_adj. (oom_score_adj valid range is -1000 to 1000). But oom_adj is maintained for compatibility I think. End of boring stuff.. :p

##You can check the minfree values (also change them) and see the app states with this Memory Manager app easily:

If you click on an app in the list and select 'more info', you can see it's oom_adj value. In my case, System UI has -12 (foreground), Home Launcher has 1 (visible group) etc.. You can check this manually in a terminal too.. but boring.. :D : (commands with output posted below)

E.g. take home launcher. Find out it's PID (process ID) like this..

$ ps |grep home
u0_a26 1653 721 471408 78076 ffffffff 00000000 S com.sonyericsson.home

It's pid is 1653. To see it's oom_adj value..

$ cat /proc/1653/oom_adj
1

It's 1 (foreground). You might get 6 (hidden). So, your home is easily killed than my home :p. See below why..

At the same time you can see the new oom_score_adj..

$ cat /proc/1653/oom_score_adj
58

To convert it to old oom_adj value..

oom_adj=(oom_score_adj x 17)/1000

So, 58 x 17 /1000 = ~1

*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! :D

[Highlight]So, the things you can do..[/highlight]

1. Change the minfree values to suit your needs. Use lower values if you want more multitasking. Higher values if need more "free ram" for gaming etc.. (see below.. what's this "free ram"?). 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!

You can set those values with the above Memory Manager app (and tick 'apply at boot'). Need root access..

Or do the boring manual way..

echo "2048,3072,11520,16640,24320,42240" > /sys/module/lowmemorykiller/parameters/minfree

(after "su" command of course; need root for that).

This won't survive reboot. You can run this command as a script with init.d every boot. (For init.d support, check this). If you have init.d support, you can use Minfree Manager app to set minfree values, and it saves a script under init.d. No hassle.

2. Use 'App Settings' xposed module to make any app "stay" in memory (make it "Resident"). It possibly reduces the oom_adj value so it won't get killed. That's why you can see Opera Mini in the Foreground app list above in my screenshot. It's oom_adj is 0. You can do this for your home launcher and any app you wan't to stay un-killed in the background.

3. Use zeppelinrox's jar patcher tools to patch services.jar, where 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.

4. With the above jar patching, you can use zeppelinrox's supercharger script to change the minfrees and re-group the OOM categories. It has tons of other tweaks. But for me, this OOM regrouping made some task killings much difficult and didn't relese ram readily when needed for heavy games.. So I'm not using it. I'm setting up minfrees as described above. There are some boring techie stuff about this OOM grouping thing.. but no need here.

5. Override the "Hidden app limit" of Android. In addition to the LMK thing described above, this is another mechanism that kills hidden and empty apps. Apps are killed when hidden app numbers go beyond the specified limit. Traditionally it's 15, so no more than 15 hidden apps will stay in the background even if there's plenty of ram. There's a build.prop setting which can control that in our SP. (Btw, jar patching mentioned above makes that limit to 70). With the build.prop setting mentioned below, we could make it to 150 :D! (This way, we can maximize multitasking and app killing is fully handed over to LMK minfrees, which we can control).

ro.sys.fw.bg_apps_limit=150

Add this line to end of build.prop file and leave another blank line below that, and reboot. Use 70, if 150 looks scary ;) [Highlight](Always keep cwm backups before doing these kind of things).[/highlight]

Credits to [MENTION=3357461]zeppelinrox[/MENTION] for finding that setting. You can read what happens and how to test it here in his thread.

One last thing about "free ram"..

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. You can see the ram usage with this.. "cat /proc/meminfo"

$ 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. ["Free RAM"=MemFree+Cached]. Out of that, most (135mb) is already cached. Actual free is very little. So, increasing "free ram" makes the phone much snappier because a larger part of the ram is used for caching things.

** I'd be more than glad if anyone points out shortcomings/improvements.

[MENTION=5765352]TechnoSparks[/MENTION], Do you think it's useful if I organize this into a thread?