Messages in this thread | | | Date | Mon, 20 Mar 2000 16:52:03 -0600 (CST) | From | Brian Hurt <> | Subject | Re: 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/
| |