> It is not clear to me why anyone would implement overcommit in the
> first place or, once the obvious problem is pointed out, why there
> should be discussion of anything other than how to fix the blunder.
The people who implemented overcommit had spent 20 years studying the real
world. And in the real world you realise
o Processes get terminated by lots of unusual events not just out of
memory - everything from fire to the office cat.
o Systems as a whole therefore have to be robust to this anyway
o There is an implicit unchecked memory allocation in normal C - stack
pages. So a stack page OOM will kill you anyway (forget calling a
function to report it, you have nothing to report it on)
> Methinks not all those folk are clueless. More likely, I've missed
> something basic here. Would someone please explain it?
For all normal uses the inconvenience of losing a process is far less than the
real resource wastage of trying to prevent it happening, and then at best
being able to stop it occuring most of the time.
What do you do for example if you need memory for a library fixup. There is
no mechanism for reporting this back.
-
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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:13 EST