ASU - out of memory?

Sander van Grieken sander at
Fri Aug 22 08:36:26 CEST 2008

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> 
> > 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.

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.


More information about the community mailing list