Alan Cox wrote:
>
> > The explanation is not the issue. The issue is having programs that
> > act correctly (check malloc() returns, don't follow null pointers,
> > etc.) fail in ways that are quite difficult for their programmers
> > to prevent.
>
> Indeed. And its completely valid to kill them off. Right now nobody
> has a serious commercial requirement for non-overcommit on Linux.
I'm seriously confused by this thread.
If I understand correctly, programs can malloc() memory, get back a
valid pointer, then segfault later when they try to use the memory.
This strikes me as quite obviously Wrong.
I can see no question about whether this is a problem. To me, it clearly
is, and a ghastly one at that. This breaks the basic behaviour of
important system calls, making memory allocation unreliable.
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.
On the other hand, I see several people, some of whom I know are
competent, defending the existing behaviour.
Methinks not all those folk are clueless. More likely, I've missed
something basic here. Would someone please explain it?
Would it make everyone happy to have tunable parameters for this?
Using R for RAM, S for swap, max Commitable is:
C = aR + bS
and sys admin sets a, b. Default is perhaps a = 1, b = .5 to keep
paging to reasonable levels, but you might have a = b = 10 on one
system to allow heavy overcommit and a = 1, b = 0 on another for
minimum swapping.
-
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