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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:24 EST