ASU - out of memory?

[Carsten Haitzler (The Rasterman)]

On Thu, 21 Aug 2008 16:09:58 +0200 Tilman Baumann <tilman at baumann.name> babbled:

> Esben Stien wrote:
> > Tilman Baumann <tilman at baumann.name> writes:
> > 
> >> all the linux memory overcommit behaviour more or less depends on
> >> the fact that it can allways save it's ass by using swap. (Instead
> >> of helplessley crashing)
> > 
> > Yes, or killing the application. 
> 
> That would be great. But was always a hot topic and AFAIK no solution 
> was found yet.
> I remember there was a proposal for a more intelligent oom killer system 
> on lkml some time ago. No idea if this is still around.
> (Was afaik some preemtive notification to userspace)
> 
> Intuitively the answer is clear. Kill the culprit and not just something 
> big. But what is to kill? And how to determine without allocating any 
> more memory...
> I have never seen any craceful oom killer yet.

really - we need a userspace "oom" that is "Smarter" (it knows what a system
daemon is and what a user application is and what is a "necessary user desktop
process"), so it will always kill "apps" not the phone daemon or the window
manager or the launcher etc. it will stick to finding "visible apps" that have
gone rogue and nuke them. the userspace oom can run as root - mlock() its
memoryspace in and give itself a realtime priority with setsched(). every
second or so - check the memory state of the system, if it begins to get low -
issue a warning signal to processes (could use dbus or something more basic
like system signals - use SIGURG or something pretty much unused these days).
any "well behaved app" when it gets such a signal should:

* free any memory it doesnt REALLY need (any caches or any data loaded that it
can get back from a file again), so save out stuff and free.
* if it does garbage collection - collect now. asap!
* if it makes sense - exit the process altogether (if it is really not a
useful process and it can be started later when things get better)

this would - allow things to clean up nicely and avoid swap storms. remember
swap comes with the cost of writing to swap AND reading back at another time.
throwing out pages from disk cache and then just loading them later if u need
them again has less cost - throwing out costs nothing, and "paging in" is (give
or take) the same cost as from swap. the kernel makes a wild guess as to what
pages are really so unused they should be swapped as cache is more useful than
those pages... but better than making the kernel HAVE to throw them into swap
is.. get rid of them entirely!

yes.. this requires work on the part of app authors in userspace. but it's the
right thing to do (imho).

anyway - the same userspace oom daemon can then choose to kill processes should
the situation become dire - and in this case it could be sure NOT to kill X,
window manager, launcher, dbus daemon etc. (important system processes that
keep the ui and user-facing bits that keep the thing usable).

:)

-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>