Messages in this thread | | | From | "Khimenko Victor" <> | Date | Mon, 27 Mar 2000 00:53:20 +0400 (MSD) | Subject | Re: Avoiding OOM on overcommit...? |
| |
In <38DBBA93.B5EF5E66@storm.ca> Sandy Harris (sandy@storm.ca) wrote: > 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.
Why ?
> If I understand correctly, programs can malloc() memory, get back a > valid pointer, then segfault later when they try to use the memory.
As well as it can segfault trying to use too deep recursive procedure if system does not have enough resources to expand stack... Or trying to use memory in some other way...
> This strikes me as quite obviously Wrong.
Why ? It happens when system just DO NOT HAVE RESOURCES to keep all programs running. Something should give up.
> 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 does not! ONCE MORE: something bad (innocent program killing or whatever) can happen ONLY when system do not have resources to continue without task killing. WHAT task should be killed is another matter. Overcommit does not affect this. Overcommit can affect task selection in such situation though.
> 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.
Since without overcommiting problem will be WORSE, not better! You system will be able to keep up LESS programs, not more. Yes, it can make decision of doomed task easier, but that's all.
> 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.
This is all just stupid and not needed. What IS needed is reasonable tracking of used memory and user-level (not task level as now) quota. You CAN crash database with or without overcommit in case of OOM. Just like you can crash said database if you'll fill all space on disk. Good database (like Oracle, DB2 or whatever) can be safely restarted again if resurces will be reclaimed.
P.S. IRIX has something akin to proposed scheme. Most admins just use b=\infty while few (much less) using a=b=1.
P.P.S. Oh, and to implement all this you need additional book-keeping of used memeory. I doubt Linus will accept such patches: in normal situation they are not needed at all and it's not clear how they can help in case of disaster...
- 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/
| |