On Wed, Dec 16, 1998 at 01:14:59AM -0800, John Nemeth wrote:
>      This problem came about when some "brilliant" person got the idea
> of overcommitting memory.  Once upon a time, when you did sbrk(2),
> swap space was allocated for the memory you wanted immediately.  If
> there wasn't enough swap space available, then the syscall failed and
> it was up to the program to figure out what to do about it.  However,
> some programs used sparse data structures, and would allocate huge
> ammounts of memory and only use a little bit of it.  They couldn't do
> this unless there were huge ammounts of swap space available.  Instead
> of smacking these programs upside the head, and telling them to use
> memory more efficiently, some "brilliant" person invented
> overcommitting of memory (I believe this was done in SysV).  With this

etc.

Yes, this is the problem. However, this is also the solutio for two problems:

a) somebody might sbrk or malloc a lot and use up all swap space... resulting
in denial of other services (and no, limit()ing is no solution... if you divide
your, say, 1 GB of swap space by your 32 users, and by the 64 processes you 
allow per-user (maximum), you end up with err... half a MB of swap space per
process, which is unusable... so you have to overcommit the limit settings.
The problem was just shiftet to another domain... it was there earlier.

b) Many modern databases depend on efficiently handled sparse data structures.

	-is