linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Chris Ross <chris@tebibyte.org>
To: Werner Almesberger <wa@almesberger.net>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Andrea Arcangeli <andrea@novell.com>,
	Jesse Barnes <jbarnes@sgi.com>,
	Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
	Andrew Morton <akpm@osdl.org>,
	Nick Piggin <piggin@cyberone.com.au>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH] Remove OOM killer from try_to_free_pages / all_unreclaimable braindamage
Date: Thu, 18 Nov 2004 00:27:15 +0100	[thread overview]
Message-ID: <419BDE53.1030003@tebibyte.org> (raw)
In-Reply-To: <20041117195417.A3289@almesberger.net>


Werner Almesberger escreveu:
> A process could declare itself as usual suspect. This would then be
> recorded as a per-task flag, to be inherited by children.

I don't think this "I know I'm buggy, please kill me" flag is the right 
approach even if it can be made to work. The operating system has an 
overview of all the memory and can see when a particular process is 
basically making the machine unusable. It's quite likely that the 
process causing the trouble doesn't know (or hasn't admitted) that it's 
buggy and hasn't volunteered for early termination. As this means the 
kernel must be able to deal with a problematic process completely 
irrespective of whether it has set "kill me" flag or not the flag 
doesn't really buy you anything.

It is also specific to runaway processes that are clearly at fault. 
There is the related case where no particular process is faulty as such 
but the system as a whole can't cope with the demands being made.

On a related note, I would prefer to see victim processes who are not 
determined to be the cause of the trouble swapped out (i.e. *all* their 
pages pushed out to swap) and suspended (not allowed to run) as a first 
resort. The example I have in mind is on my machine when the daily cron 
run over commits causing standard daemons such as ntpd to be killed to 
make room. It would be preferable if the daemon was swapped out and just 
didn't run for minutes, or even hours if need be, but was allowed to run 
again once the system had settled down.

Of course, from recent discussion the system should not actually be 
killing off these daemons at all but that does seem to be resolved now. 
There are circumstances when there simply isn't enough RAM and swapping 
something out is preferable to killing it off. Of course, if there isn't 
sufficient swap space killing it should be the second resort. The last 
resort being panic.

So, the problem breaks down into three parts:

	  i) When should the oom killer be invoked.
	 ii) How do we pick a victim process
	iii) How can we deal with the process in the most useful manner

Regards,
Chris R.

--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2004-11-17 23:27 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-05 20:01 Marcelo Tosatti
2004-11-05 23:32 ` Jesse Barnes
2004-11-05 23:47   ` Thomas Gleixner
2004-11-06  1:20   ` Andrea Arcangeli
2004-11-06  1:26     ` Nick Piggin
2004-11-06  1:36       ` Jesse Barnes
2004-11-06  1:50       ` Andrea Arcangeli
2004-11-06  9:47         ` Hugh Dickins
2004-11-06 10:53           ` Nick Piggin
2004-11-06 15:29             ` Andrea Arcangeli
2004-11-06 15:29           ` Andrea Arcangeli
2004-11-06 16:21             ` Hugh Dickins
2004-12-10  6:02               ` William Lee Irwin III
2004-11-06 11:37         ` Nikita Danilov
2004-11-06 15:32           ` Andrea Arcangeli
2004-11-06 16:54             ` Nikita Danilov
2004-11-06 17:44               ` Andrea Arcangeli
2004-11-06 19:24                 ` Nikita Danilov
2004-11-07  1:16                   ` Andrea Arcangeli
2004-11-06 10:11       ` Marcelo Tosatti
2004-11-06  1:55     ` Thomas Gleixner
2004-11-06 10:28       ` Marcelo Tosatti
2004-11-17 22:54       ` Werner Almesberger
2004-11-17 23:27         ` Chris Ross [this message]
2004-11-18  0:04           ` Werner Almesberger
2004-11-18  0:28             ` Chris Ross
2004-11-18  1:14               ` Werner Almesberger
2004-11-18  8:20                 ` Chris Ross
2004-11-18 10:01                   ` Werner Almesberger
2004-11-18 14:44                     ` Thomas Gleixner
2004-11-18 15:10                       ` Chris Friesen
2004-11-06 10:05     ` Marcelo Tosatti
2004-11-06 15:44       ` Andrea Arcangeli
2004-11-06 15:52         ` Arjan van de Ven
2004-11-06 17:09         ` Marcelo Tosatti
2004-11-07  0:48           ` Andrea Arcangeli
2004-11-07 11:21             ` Marcelo Tosatti
2004-11-06 12:53 ` [PATCH] Remove OOM killer Andries Brouwer
2004-11-06 10:41   ` Marcelo Tosatti
2004-11-07  9:26   ` Marko Macek
2004-11-08 16:27 ` [PATCH] Remove OOM killer from try_to_free_pages / all_unreclaimable braindamage Marcelo Tosatti

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=419BDE53.1030003@tebibyte.org \
    --to=chris@tebibyte.org \
    --cc=akpm@osdl.org \
    --cc=andrea@novell.com \
    --cc=jbarnes@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=marcelo.tosatti@cyclades.com \
    --cc=piggin@cyberone.com.au \
    --cc=tglx@linutronix.de \
    --cc=wa@almesberger.net \
    /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