That's not the kind of "overallocating" that's going on. (Well, with the
malloc() => mmap() stuff it is, but that's not where the real problems are.
After all, the malloc() => mmap() stuff can at worst be handled by raising
SIGSEGV.)
The issue is swap overcommit, meaning delayed allocation of backing swap
pages for memory pages. And yes, most programs in a non-overcommitting OS
*do* end up allocating backing swap that is never used.
Basically, you have two choices:
(1) no swap overcommit, you must run with huge amounts of swap most of which
will *never* be used;
(2) swap overcommit, where occasionally the system needs to swap something
and no free pages are available, and when this is discovered the system
can't back off. (Usually either this case doesn't occur or the system can
refuse; but if it happens after the system has committed to providing memory
for something, you're SOL.)
It is instructive to experiment with systems where the behavior is
selectable. For example, OS/2 allows you to enable/disable overcommit at
boot time: if the MEMMAN setting in CONFIG.SYS includes "COMMIT" then OS/2
does not overcommit swap. Try it sometime and watch how big your swap file
gets --- and make sure your swap file is on a BIG partition when you turn on
COMMIT, because you'll need it.
-- brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering KF8NH carnegie mellon university
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/