ASU - out of memory?

Carsten Haitzler (The Rasterman) raster at openmoko.org
Fri Aug 22 02:59:25 CEST 2008


On Thu, 21 Aug 2008 19:54:26 +0200 Sander van Grieken <sander at 3v8.net> babbled:

> On Thursday 21 August 2008 19:33:24 Steven Kurylo wrote:
> > > And come on. Software is not perfect. Sometimes we have to live with a
> > > dreamteam like (old) firefox and x11. I had times when they had both
> > > hundreds of megs virtual mem. But everything was fine because it all was
> > > just harmlessly been swaped away. I restarted them every weekend to not
> > > let it become worse.
> > > Not ideal, but should the system rather be unusable in this condition?
> >
> > You're assuming the system will be usable when an application
> > misbehaves and 50mb gets swapped out.  On a desktop, sure your points
> > are valid.
> >
> > I'm not sure this is true on Freerunner.  None of the embedded systems
> > I've used have had swap.  What happens when you haven't received a
> > call for several hours and the application you're using forces it to
> > swap out?  Can you still answer a call in time?
> 
> Exactly.
> 
> > I'd rather see a smart oom killer which will only kill non-essential
> > applications.  Adding 128mb of swap just pushes the problem back and
> > slows down the entire phone.
> 
> 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.


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




More information about the community mailing list