On Thu, 21 Aug 2008 19:54:26 +0200 Sander van Grieken <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]> _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
