lkml.org 
[lkml]   [2000]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Overcommittable memory
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.043 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site