ASU - out of memory?

[Carsten Haitzler (The Rasterman)]

On Fri, 22 Aug 2008 08:36:26 +0200 Sander van Grieken <sander at 3v8.net> babbled:

> On Friday 22 August 2008 02:59:25 Carsten Haitzler wrote:
> > On Thu, 21 Aug 2008 19:54:26 +0200 Sander van Grieken <sander at 3v8.net> 
> babbled:
> > > For a phone, the algorithm could be as simple as killing the process that
> > > has allocated the most memory. The essential system services and the
> > > basic UI applications usually have a small footprint, and the biggest
> > > consumer of memory is most likely a leaky UI app that's not part of the
> > > main system anyway.
> > >
> > > For a production server with large databases this doesn't work of course,
> > > but there you're already in big trouble if you have to fallback on the
> > > oom-killer.
> >
> > true - and the kernel oom killer should mostly handle this, BUT it is
> > possible to do better. a userspace oom killer can trawl all .desktop files
> > and thus know if the app is run by a user (base on command), or if its a
> > system app that can be run, or if its installed later etc. etc.
> >
> > such a userspace oom isn't hard to do. it's pretty simple.
> 
> Problem is, your might not have the memory to trawl those .desktop files.

thus my original "write a root daemon - setsched() to realtime priority and
mlock() memory space down! (and of course read every page of memory to make
sure it's paged in) :)

> What about a malloc that's LD_PRELOADed in front of non-essential apps, that 
> enforces a 5-10% available memory for essential system and phone apps? (or 
> maybe some other hook mechanism if preloading is not feasible)
> 
> Of course there also should be such wrappers for delegated allocators like
> the X pixmap example your mentioned earlier.

yeah. though such a userspace oom could use xresource extension to track x
client usage too and do the same as it would rummaging through /proc
regularly :)

> Sander
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


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