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