Taming the OOM killer
Posted Feb 5, 2009 8:22 UTC (Thu) by brouhaha
In reply to: Taming the OOM killer
Parent article: Taming the OOM killer
swap isn't free, especially on embedded systems
I have yet to use an embedded Linux system that didn't have substantially more "disk" than RAM, except one case in which there was no disk but plenty of RAM. I somewhat question the wisdom of designing an embedded Linux system for which there is little RAM and even less disk.
In an embedded system, I wouldn't expect there to be a large number of processes sleeping between a fork() and exec(). If there were, that would most likely be a sign of serious problems, so having a fork() fail under such circumstances seems like a good thing.
also, actually _using_ swap can be extremely painful, sometime more painful than simply crashing the system
Sure, but when copy-on-write is used for the fork()/exec() case that seems to be what people are worried about, the swap won't actually be used. It will just be reserved until the exec().
If you're concerned about system performance degrading because of excessive swap usage, there's no reason why you can't have a user-space process to act as a watchdog for that problem, which may occur for reasons other than memory "overcommit".
I've been involved in engineering a number of embedded products that had to have high reliability in the field, and I would not dream of shipping such a product with the kernel configured to allow memory overcommitment. Even though you can _usually_ get away with it, "usually" isn't good enough. There simply needs to be enough memory (and/or swap) to handle the worst-case requirements of the system. Otherwise it _will_ fail in the field, and thus not be as reliable as intended.
to post comments)