lkml.org 
[lkml]   [2000]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Some questions about linux kernel.
One thing I find disturbing about this whole debate is the assumption that
the only valid response a program can make to running out of memory is to
crash- and that it doesn't matter if the crash is a SEGV or a more
controlled cleanup & exit.

One can even imagine better responses a program might have to being unable
to allocate memory than simply exit, too- initiating a garbage collection
to free up it's own internal memory, or having a prepared dialog box that
it can show that says "Unable to allocate memory- please close some other
programs and try again".

On Mon, 20 Mar 2000, James Sutherland wrote:

> On Mon, 20 Mar 2000 12:00:52 -0400, you wrote:
>
> >orc@pell.portland.or.us (david parsons) said:
> >> In article <linux.kernel.Pine.LNX.4.10.10003171319000.3718-100000@dax.joh.cam.ac.uk>,
> >> James Sutherland <jas88@cam.ac.uk> wrote:
> >
> >[...]
> >
> >> >In fact, it makes the problem worse.
> >>
> >> If the problem is an intruder on your system who is attempting a
> >> deliberate denial of service attack, maybe. If the problem is a
> >> program allocating more memory than there is in the system and
> >> making a different program die because of the overcommit,
> >> non-overcommit is the best solution to this feature.
> >
> >If one program allocates just shy of what is available, it will succeed.
> >The next one the can't get the memory it needs and crashes. Exactly as in
> >the overcommiting case: Innocent bystanders get shot, just earlier (or even
> >much earlier) if you don't overcommit. And with a clean bullet through the
> >head (malloc(3), or fork(2), fails), not by a random shot at the body
> >(SIGSEGV when accessing memory that "should be there"). End result is the
> >same.
>
> *IF* there is genuinely not enough VM, then yes, both systems result
> in the same outcome. If, OTOH, there IS enough, but only just,
> overcommit allows some operations to succeed which would otherwise
> have been impossible.
>
> So: Under some circumstances, the ABSENCE of overcommit will cause
> problems. Having overcommit cannot make things worse, and makes the
> system much less resource intensive (=>cheaper).
>
>
> 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/
>


-
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.101 / U:1.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site