Messages in this thread | | | From | James Sutherland <> | Subject | Re: Overcommittable memory | Date | Sun, 19 Mar 2000 21:36:29 +0000 |
| |
On Sat, 18 Mar 2000 12:06:34 -0500, you wrote:
> >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.
It's a bit late to do that now :-)
Basically, we are presented with a fait accompli: At least one process dies. Which one? The most appropriate answer in most cases is "the biggest" (with a few modifications to favour killing newly started processes etc.)
> Overcommitting memory just hides the >problem and makes it more difficult to track down, and in the end just >encourages sloppy code.
Not significantly, IMO; allocating memory on use rather than on request is just an optimisation. (It allows much simpler code in many cases; you can just malloc() a sparse array safely, for example.)
>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.
Not really; remember, the stack is also demand-allocated.
>However, I recognize that overcommit is a feature that many people >want; it would be nice if it were selectable however.
There are some specialist applications where you may want/need this fine-grained control over your app's memory usage and stack size - but the main Linux kernel is not the right place for this, IMO.
James.
- 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/
| |