Messages in this thread | | | Date | Sat, 18 Mar 2000 12:06:34 -0500 | From | Mirian Crzig Lennox <> | Subject | Overcommittable memory |
| |
In article <Pine.LNX.4.05.10003171413560.13654-100000@humbolt.nl.linux.org>, Rik van Riel <riel@nl.linux.org> wrote: >On Fri, 17 Mar 2000, Stephen C. Tweedie wrote: > >I'd really like the non-overcommit fans to come up >with a good reason why a non-overcommitting system >doesn't suffer from the same problem, but all I've >seen so far are changes to the problem :) >(and no, I don't believe there is any solution to >OOM on any system that allows userspace to dynamically >allocate memory ....)
I've recently just entered this discussion. However, it interests me because in my paying job I write OS code for an embedded computer, and am very familiar with the issues of low memory.
If you are in an OOM situation, there are roughly two possible causes: 1. You plainly don't have enough vm in your system for normal operation. 2. Some application is leaking memory.
If the situation is #1, there's really not a lot you can do except get more memory... but if the problem is that you're leaking memory then you should FIX THE DAMN APP. Overcommitting memory just hides the problem and makes it more difficult to track down, and in the end just encourages sloppy code.
Furthermore, even if you are in condition #1, overcommitting memory might make the OOM situation more rare, but it will be much more catastrophic when it hits. It is much easier to write applications which are robust about memory allocation in a non-overcommit environment.
However, I recognize that overcommit is a feature that many people want; it would be nice if it were selectable however.
--Mirian
- 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/
| |