Let's try to bring this discussion into focus, because it seems
worthwhile, despite it having degenerated into a religious war.

Let's start from the other end:

If *BSD _did_not_have_ the means to overcommit, would one want to
add them?  I think the obvious answer here is a resounding "Yes",
so we should accept Matthew Dillon's perspective as valid on this
score..

In general, the point the anti-over-commitment camp keeps raising
is always quite correctly shot down by Matthew, if you're not going
to run out of swap, then overcommitment can't hurt you.

On the other hand, just because there is a hammer solution, that
does not mean that all problems are nails.  There has to be a
mechanism to protect valuable processes from accidental or intentional
abuse of resources.  Adding more disk space is not always a solution
and Matthew himself pointed out that there comes a time when swapping
turns to thrashing, at which point too much swap space is a liability
not an advantage.  If you have _no_ swap space, you're no better off.

Personally, I think over-commitment should be switchable on and off
at the process level, and there should be an inheritance flag for
child processes to do the right thing too.

In addition, a global danger signal, probably providing a bit mask
that indicates _which_ condition is creating a crisis, some hysteresis
as Jason (I seem to recall) requested, and possibly some means of
retrieving the identification of the last process to trigger a crisis,
should all be available in the overcommit context.

Unless I'm reading the debate wrong, SIGDANGER is not required when the
system returns NULL if memory is exhausted.  Of course, there's nothing
that says the semantics of SIGDANGER may include some hysteresis, in which
case it could be useful in either context.

It may be preferable to combine all these semantics into a single library
function (don't ask me, I'm only a user :-) that simplifies the otherwise
complex interface.  But the bottom layer must be there for those who may
want to do some fine tuning.

++L