[Samsung Galaxy Nexus] Khrushy:
There's no memory killer in the Franco app - and unless you're setting oom_kill_allocating_task to 1 in your init.d, then it shouldn't be murdering background tasks like Whatsapp unless they're acting up in the background and *should* be murdered.

One possible thing I can think of is - what's your uptime? The current Franco has vm_swappiness = 0, and a very low cache pressure, meaning the kernel basically never releases memory unless it absolutely has to. If you have a long uptime, it's possible your system is already hogging all the memory, and that's what's causing the background apps like Whatsapp or Gmail to play up.

Easiest way to test is to do a reboot. If you don't have that problem straight after reboot - only when you have a large uptime, then it's about the kernel being a memory hog in the longer term. One possible solution might be to try putting these values into your init.d instead and see if that improves things.

echo 30 > /proc/sys/vm/swappiness

echo 100 > /proc/sys/vm/vfs_cache_pressure

No guarantees though. Weird OOM issues are mostly caused by some app acting up in the background, and can be really random in how they show up.

---------- Post added at 12:47 AM ---------- Previous post was at 12:06 AM ----------

I spent quite a bit of time playing with these settings a while ago, and I'm still a bit undecided about what to think of Imoseyon's advice. When using Deadline, and just using the phone for everyday tasks it seems like his values work well, but I didn't notice any significant improvements. When I go into heavy multitasking mode I found them to induce some large but infrequent stutter.

Once I switched to the cfq it became really clear that the optimal setup for use with that scheduler (also noop) is to have much lower dirty ratios, and much faster writeback times, to ensure that whenever you were writing data to disk, you were doing so in small, regular doses, which I, the user, didn't even notice. With the higher dirty ratios (70+) it became really obvious (and laggy) on the occasions when the system was writing to disk while I was doing other stuff.

It's one of those cases where the different aims of the IO schedulers really mean that different settings are required. Deadline's main goal is to ensure no process, regardless of what's happening, gets starved of resources (but it uses slightly more overhead doing so). CFQ basically just tries to evenly split resources. What the single "best" way to write memory to disk with those two very different scheduler aims in mind is a tough call.

I'm also really curious as to how Android's memory handling has changed since those posts were made. It's over 2 years, and 3 versions of Android later, and it seems like almost all the custom ROMs (CM / AOKP / etc) are still using those vm settings, despite the fact that both Android, and the hardware we're running it on, has changed momentously. 2 years ago 90% of a phone's available memory was, what? 380mb? The Gnex, which is now getting on in age, has 700MB available.

If anyone has any reading material about how they've changed any of the memory management since Gingerbread, I'd be curious to read it.

/end rambling post.

Cheers

Edit 2:

So my last comment at the end the post above made me realise I’ve been looking at the vm_dirty stuff all wrong. Given the much larger memory available in the GNex and other current devices the vm dirty ratio doesn’t really matter at all – even my lowered settings of 20(%) and 10(%) still come up with a minimum of at least 70MB, which is a pretty massive file write under normal usage.

So assuming you’re not going to hit that limit very often, it’s the dirty expire and dirty writeback that dominate how frequently you’re writing out the dirty pages.

Currently I’ve got this set to 2 and 5 seconds respectively (200 and 500 centiseconds), which is pretty fast, and why I suspect I’m finding the writes are basically unnoticeable. I’m not entirely sure if there’s a major downside to flushing the old dirty data this frequently or not. Currently I don’t think so, but I’m still looking to check.

Secondly, I reset my vm.vfs_cache_pressure back to 100 (previously 300) as a starting point. Given the relatively small size of the filesystem on the GNex, I don’t see a reason to be that aggressive about clearing the inode caches. I might try lowering it further after I finish playing with the vm dirty stuff.