linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
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: 22 Mar 2001 09:41:56 -0700	[thread overview]
Message-ID: <m14rwl3gdn.fsf@frodo.biederman.org> (raw)
In-Reply-To: Guest section DW's message of "Thu, 22 Mar 2001 12:47:27 +0100"

Guest section DW <dwguest@win.tue.nl> writes:

> 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.

Not killing init provides enough for recovery if you truly hit
an out of memory situation.  With 2.4.x at least it is a box
misconfiguration that causes it.   The 2.2.x VM doesn't always try
to swap, and free things up hard enough, before reporting out of
memory.  But even the 2.2.x problems are rare.

> 
> > 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.)

swap < RAM. ouch!  This is a misconfiguration on a machine that
actually starts swapping, and where out of memory problems are a
reality.  The fact an installer would trigger swapping on a 256MB
machine is a second problem. 

> 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.
> (I think 2.4.0.)

It looks like you didn't have enough resources on that machine
period.  I pretty much trust 2.4.x in this department.  Did that
machine also have it's swap misconfigured?

> 
> Clearly, Linux cannot be reliable if any process can be killed
> at any moment. I am not happy at all with my recent experiences.

Hmm.  It should definitely not be at any moment.  It should only be
when resources are exhausted.  So putting enough swap on a machine
should be enough, to stop this from ever happening.

Eric
--
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-22 16:41 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 [this message]
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
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=m14rwl3gdn.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --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