On Dec 15,  1:33pm, Jukka Marin wrote:
} On Tue, Dec 15, 1998 at 12:19:33PM +0100, Ignatios Souvatzis wrote:
} > > I know there isn't a simple a perfect solution to this, but I would rather
} > > have a Netscape process killed by the system than have the whole server die
} > > or lock up.  I guess this isn't much of a problem on a single-user machine
} > 
} > The problem is when the shortage happens, you simply don't know who the "right"
} > culprit to kill is.
} > 
} > Netscape might get N-20 pages of swap, then, say, some small cron job might
} > need 25. It might be possible to implement to kill the last process needing
} > swap, but this wouldn't be necessarily right.
} 
} Yes, I know this problem..  I also know that sometimes a reboot is better
} than just killing off a process (wouldn't help much to have a telnet or pop
} server running with its inetd dead).

     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
you could sbrk(2) to your heart's content since the swap pages were
only allocated when you actually used the memory.  This, of course,
created a problem, what to do if the memory used by all processes
exceeds the ammount of virtual memory the system actually has?  The
usual answer is to kill a process.  This raises the question of which
process to kill?  There are no easy answers to this question.  The
other option would be to put the process to sleep until memory is
available, but this isn't necessarily a good solution either.
Overcommitting memory is really evil, and I sure hope NetBSD doesn't
do it.  If it does, then there should be some way of disabling it.

} But still I believe that it should be possible to configure a UN*X system
} so that no non-root user can crash it or make it unusable in some other way.

     This is a nice theory, but very hard to do in practice.

}-- End of excerpt from Jukka Marin