linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "James A. Sutherland" <jas88@cam.ac.uk>
To: Guest section DW <dwguest@win.tue.nl>
Cc: Rik van Riel <riel@conectiva.com.br>,
	Patrick O'Rourke <orourke@missioncriticallinux.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Prevent OOM from killing init
Date: Fri, 23 Mar 2001 17:26:22 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.30.0103231721480.4103-100000@dax.joh.cam.ac.uk> (raw)
In-Reply-To: <20010322124727.A5115@win.tue.nl>

On Thu, 22 Mar 2001, Guest section DW wrote:
> On Wed, Mar 21, 2001 at 08:48:54PM -0300, Rik van Riel wrote:
> > On Wed, 21 Mar 2001, Patrick O'Rourke wrote:
>
> > > Since the system will panic if the init process is chosen by
> > > the OOM killer, the following patch prevents select_bad_process()
> > > from picking init.
>
> There is a dozen other processes that must not be killed.
> Init is just a random example.

That depends what you mean by "must not". If it's your missile guidance
system, aircraft autopilot or life support system, the system must not run
out of memory in the first place. If the system breaks down badly, killing
init and thus panicking (hence rebooting, if the system is set up that
way) seems the best approach.

> > One question ... has the OOM killer ever selected init on
> > anybody's system ?
>
> Last week I installed SuSE 7.1 somewhere.
> During the install: "VM: killing process rpm",
> leaving the installer rather confused.
> (An empty machine, 256MB, 144MB swap, I think 2.2.18.)

If SuSE's install program needs more than a quarter Gb of RAM, you need a
better distro.

> Last month I had a computer algebra process running for a week.
> Killed. But this computation was the only task this machine had.
> Its sole reason of existence.
> Too bad - zero information out of a week's computation.

A computation your system was incapable of performing. OK, it's a shame it
took you a week to find this out, but the computation had to die: if the
only process running cannot run, it has to die!

> (I think 2.4.0.)
>
> Clearly, Linux cannot be reliable if any process can be killed
> at any moment.

What on earth did you expect to happen when the process exceeded the
machine's capabilities? Using more than all the resources fails. There
isn't an alternative.


James.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

  parent reply	other threads:[~2001-03-23 17:26 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-21 22:54 Patrick O'Rourke
2001-03-21 23:11 ` Eli Carter
2001-03-21 23:40   ` Patrick O'Rourke
2001-03-21 23:48 ` Rik van Riel
2001-03-22  8:14   ` Eric W. Biederman
2001-03-22  9:24     ` Rik van Riel
2001-03-22 19:29     ` Philipp Rumpf
2001-03-22 11:47   ` Guest section DW
2001-03-22 15:01     ` Rik van Riel
2001-03-22 19:04       ` Guest section DW
2001-03-22 23:10         ` Jordi Polo
2001-03-22 16:41     ` Eric W. Biederman
2001-03-22 20:28     ` Stephen Clouse
2001-03-22 21:01       ` Ingo Oeser
2001-03-22 21:23       ` Alan Cox
2001-03-22 22:00         ` Guest section DW
2001-03-22 22:12           ` Ed Tomlinson
2001-03-22 22:52           ` Alan Cox
2001-03-22 23:27             ` Guest section DW
2001-03-22 23:37               ` Rik van Riel
2001-03-26 19:04                 ` James Antill
2001-03-26 20:05                   ` Rik van Riel
2001-03-22 23:40               ` Alan Cox
2001-03-23 20:09                 ` Szabolcs Szakacsits
2001-03-23 22:21                   ` Alan Cox
2001-03-23 22:37                     ` Szabolcs Szakacsits
2001-03-23 19:57           ` Szabolcs Szakacsits
2001-03-22 22:10         ` Doug Ledford
2001-03-22 22:53           ` Alan Cox
2001-03-22 23:30             ` Doug Ledford
2001-03-22 23:40               ` Alan Cox
2001-03-22 23:43         ` Stephen Clouse
2001-03-23 19:26         ` Szabolcs Szakacsits
2001-03-23 20:41           ` Paul Jakma
2001-03-23 21:58             ` george anzinger
2001-03-24  5:55               ` Rik van Riel
2001-03-24  8:04                 ` Mike Galbraith
2001-03-27 14:05                 ` Scott F. Kaplan
2001-03-28  0:00                   ` Rik van Riel
2001-03-30  3:18                     ` Scott F. Kaplan
2001-03-30 23:03                       ` Rik van Riel
2001-03-23 22:18             ` Szabolcs Szakacsits
2001-03-24  2:08               ` Paul Jakma
2001-03-23  1:31       ` Michael Peddemors
2002-03-23  0:33       ` Martin Dalecki
2001-03-22 23:53         ` Rik van Riel
2002-03-23  1:21           ` Martin Dalecki
2001-03-23  0:20         ` Stephen Clouse
2002-03-23  1:30           ` Martin Dalecki
2001-03-23  1:37             ` Rik van Riel
2001-03-23 10:48               ` Martin Dalecki
2001-03-23 14:56                 ` Rik van Riel
2001-03-23 16:43                   ` Guest section DW
2001-03-24  5:57                     ` Rik van Riel
2001-03-25 16:35                       ` Guest section DW
2001-03-23 17:26     ` James A. Sutherland [this message]
2001-03-23 17:32       ` Alan Cox
2001-03-23 18:58         ` Martin Dalecki
2001-03-23 19:45           ` Jonathan Morton
2001-03-23 23:26             ` Eric W. Biederman
2001-03-25 13:54           ` [PATCH] OOM handling Martin Dalecki
2001-03-25 15:06             ` Rik van Riel
2001-03-25 15:20               ` Martin Dalecki
2001-03-25 17:08                 ` Rik van Riel
2001-03-25 15:44               ` Jonathan Morton
2001-03-25 15:47                 ` Martin Dalecki
2001-03-25 16:36                   ` Jonathan Morton
2001-03-26 21:34                     ` Kevin Buhr
2001-03-26 22:00                       ` Jonathan Morton
2001-03-25 15:30         ` [PATCH] Prevent OOM from killing init Martin Dalecki
2001-03-25 20:47           ` Stephen Satchell
2001-03-25 21:51             ` [PATCH] non-overcommit memory, improved OOM handling, safety margin (was Re: Prevent OOM from killing init) Jonathan Morton
2001-03-27 15:23               ` Pavel Machek
2001-03-23 20:16       ` [PATCH] Prevent OOM from killing init Jordi Polo
2001-03-24  0:03       ` Guest section DW
2001-03-24  7:52       ` Doug Ledford
2001-03-22 14:53   ` Patrick O'Rourke
2001-03-22 19:24   ` Philipp Rumpf
2001-03-22 22:20   ` James A. Sutherland
2001-03-23 17:31   ` Szabolcs Szakacsits
2001-03-24  5:54     ` Rik van Riel
2001-03-24  6:55       ` Juha Saarinen
2001-03-22 11:08 Heusden, Folkert van
     [not found] <4605B269DB001E4299157DD1569079D2809930@EXCHANGE03.plaza.ds.adp.com>
2001-03-22 16:29 ` Rik van Riel
2001-03-22 18:32   ` Christian Bodmer
     [not found] <20010323015358Z129164-406+3041@vger.kernel.org>
2001-03-23  7:04 ` Rik van Riel
2001-03-23 11:28   ` Guest section DW
2001-03-23 14:50     ` Eric W. Biederman
2001-03-23 17:21       ` Guest section DW
2001-03-23 20:18         ` Paul Jakma
2001-03-24 20:19           ` Jesse Pollard
2001-03-23 23:48         ` Eric W. Biederman
2001-03-23  9:28 Heusden, Folkert van

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.30.0103231721480.4103-100000@dax.joh.cam.ac.uk \
    --to=jas88@cam.ac.uk \
    --cc=dwguest@win.tue.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=orourke@missioncriticallinux.com \
    --cc=riel@conectiva.com.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox