[Nexus 7 Original Development] Geko45:
I really shouldn't have to explain basic Android memory management to you. Especially considering I linked you to a 100+ page thread that discusses how and why ParrotMod helps here, but sure here goes.

The first thing you should understand about Android is that it adopts the philosophy that empty RAM is wasted RAM. To that end, it keeps as many activities as possible in memory even after the user has left them. This way, if the user needs to go back to one of them (which is the most likely case) it can be brought back to the foreground very quickly which provides the smoothest user experience possible. But what happens when the user starts a new activity that isn't in memory and the majority of memory is used by old activities? The answer is that memory must be made free to accommodate it.

This is where Android's low memory killer comes into play. It's always running in the background monitoring the amount of free memory and ensuring at least some is available for new activities (but also keeping as many existing activities in memory as possible). It attempts to anticipate the requirement for free memory by closing out old activities as needed to maintain a buffer of free RAM. But here is the kicker, when it does so it writes the old activity's state to storage so that it can still be brought back to exactly where it was left off should the user request it. This is why you can see pretty much everything you've ever opened in your Recents panel on Android and still go back to it.

Now, in a healthy and well designed device this all works very well. The low mem killer has no problem saving the state of processes and closing them out fast enough to keep up with the user's demand for memory for new activities, but on the Nexus 7 2012 devices this scheme comes flying off the rails due to the high IO latency of the device's inferior solid state storage. Since low mem killer has to save the state before it can release the memory and these writes are pathetically slow on the Nexus 7, it is very easy for the user's new memory demands to outpace the low mem killer. When that happens, requests for memory by the new activity hang while waiting for low mem killer to make it available which in turn is hanged waiting for activity state storage writes to finish. The result is horrendous lag for the user and/or multiple FCs when the new activity's memory requests fail.

So, all I'm really doing here is creating more of a buffer before this inevitable back up of writes occur which hopefully allows the user to perceive a smoother experience even though much less is actually being kept in memory. If you followed this explanation at all then you'll probably ask why not adjust the low mem settings and the answer is that ParrotMod does this too and that part of it was already working with this 3.4 kernel. All I did was fix the part of ParrotMod that doesn't work with this kernel (as best I could). The IO latency on these devices is so bad that every little bit helps. I'm also implementing tweaks on my device like setting noatime so writes won't be generated just to update last access times and I've also disabled logcat and formatted data to f2fs (again to workaround the poor write performance of these devices).

Except if you read the thread then you would know that this isn't really the direction they are going with this project. They want to make a kernel and ROM that are as stock as possible that others can use as a base to build from. So, kernel tweaks of this sort are beyond their scope. Maybe they'll change their mind. I don't know, but rather than just beg for features like most here do I chose to try to contribute something new and port ParrotMod over to their 3.4 kernel (at least for MM). If you don't like my idea then feel free to not use it. Or even better, write your own script or tweak to address the IO latency problem in grouper and talapia devices. I'm sure everyone here would love to see what you have in mind.