ASU - out of memory?

[Clinton Ebadi]

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

> 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)
[...]
> yes.. this requires work on the part of app authors in userspace. but it's the
> right thing to do (imho).

You've just rediscovered one of the few good design decisions of the
l4hurd project. See the bits on memory allocation in [0]. 'Tis a shame
that Hurd has pretty much failed (l4hurd and ngHurd got closer and
closer to fixing the terrible flaws of Mach Hurd ... but, alas, l4
stagnated and Coyotos has yet to appear dooming us to another 30 years
of UNIX it seems).

[0] http://www.walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf

-- 
Corinne: rub a dub dub nekked in the tub