[Wildfire General] henkdv:
The idea that you can magically "supercharge" your OS by freeing up memory is fundamentally flawed.

If this is really a problem on your phone, you're doing it wrong. I haven't done anything to free up ram and the amount of ram available on my wildfire is currently 108,48MiB. I start 10 random apps, Angry Birds, and Angry Birds Rio. 40,68MiB still free. I start Angry Birds Seasons and end up with 49,66MiB free and 9 apps died, including the first angry birds. Running out of ram is in general not a failure mode of Android and at no point was I unable to place a call. I close the 2 remaining open instances of Angry Birds the normal back-button way, 147,68MiB free.

I just wanted to quote that.

That's exactly the impression I had. Now take it from someone who has run Linux both embedded and on his desktop for the past 12 years. Your app doesn't improve anything, and I'd be glad to be proven wrong because you would've actually made a discovery we can use to improve Android and Linux with. From your post I understand it you change vm kernel parameters such that the oom killer is invoked sooner. This is actually detrimental to the stability of the OS, the oom killer is only meant to be invoked as a _last_resort_. The Android framework has its own means to free up memory, including calling onLowMemory in any application and doing a gc run. This does not cause instability and is completely transparent to the user. I've only ever had to manually kill applications in a broken state and others for debugging purposes, which is why the Force Close button exists.

If the output looks anything like this:

total used free shared buffers cached
Mem: 3456 3325 131 0 10 93
-/+ buffers/cache: 3221 235

Then you've just never bothered to look. You can clearly see in the second line it makes a calculation for you which is exactly what it says in the leftmost column. And of course completely disregard the fact that cached pages are invalidated on a write (marked dirty) and reads from an mtd are really fast already anyway.

This is not how it works! For starters, ram cannot be "clogged". A drain pipe can be clogged but ram is made of digital circuitry, not plumbing. And second, there is no resource starvation in the page cache. It's just an old optimisation to keep data pages in memory for longer to serve repeated reads and give them back whenever they're needed for something else. More apps in ram can actually mean less reads are necessary because the data is already there (especially if you tend to switch between recent apps). Since Android 3.0, application developers are encouraged to use Loaders which cause filesystem I/O to be performed on a background thread. And applications which actually use the available ram always trump applications designed to use as little ram possible in performance. Between a collection of loaded objects and a cached filesystem, the collection always wins. You have 256 to 512 MiB of RAM in a typical Android device. The average application is 18 to 30 MiB. It can manage. Especially when you consider the fact that the UI only shows 1 task at a time and pressing the back button usually destroys the activity you were in. The gc takes care of its remains.

Now here's something which will actually improve write speeds on /data: Open up settings, applications, manage applications. Sort by size. Remove the biggest apps you don't need and move the rest to SD if you can (you can use "pm setInstallLocation 2" as root to move non-froyo-aware apps to SD). I've been using the market a lot lately so I just removed aDosBox, Albert Heijn, PocketCloud, Pulse and moved Dolphin Browser to SD which meant 47.25MiB free on /data. On a 175MiB partition, 30% of it is about 52MiB so I'd try to keep the available space around 50MiB. If your phone is low on storage, doing this will perceivably improve performance.