On Wed, 2007-02-28 at 12:36 -0800, Gordon Messmer wrote:
Aaron Konstam wrote:
> Well this is an interesting article but it tells one nothing about swap
> fits into the virtual memory structure for the 2.4 kernel in this case.
No, but it does cover the "overcommit" feature of the Linux VM.
Understanding overcommit and the requirements of fork() in a posix
environment are critical to deciding how much swap you need.
The only point I am
trying to make is that strictly speaking in a VM
system when the memory gets full segments (or pages) from memory are
sent back to the disk (in the place on the disk where they come from).
The swap area has a system of indexing the pages it contains that allows
the system to retrieve segments (or pages) from the swap area faster
than they can be retrieved from the regular disk partition. What Unix
(and Linux) introduced is a algorithm to decide under what circumstances
the strict requirements of a VM system would be violated and segments
(or pages) would be temporarily placed in the swap space rather than
back into their original position on the disk. Unless you know under
which circumstances this occurs you can't really evaluate your need for
Generally, the overcommit feature may allow some things to work better,
but introduces some serious problems when the assumptions behind
overcommit don't apply. Hence, it's off by default. If you're not
using overcommit, then you should have considerably more swap than you
intend to actually use. Swapping is slow, and many people prefer to
have very little because they believe that if they allow memory use to
grow that large, the system will be very slow to respond. In some cases
they are right. However, if you have insufficient swap, the login
processes may not be able to fork, and you may not be able to log in and
correct the problem. Larger applications may be unable to fork, and use
external helpers, even when there appears to be sufficient memory for
I'm of the opinion that it's best to have plenty of swap, as previously
A penny saved kills your career in government.
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam(a)sbcglobal.net