Messages in this thread | | | Date | Fri, 24 Mar 2000 13:57:23 -0500 | From | Sandy Harris <> | Subject | Re: Avoiding OOM on overcommit...? |
| |
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/
| |