From: Gerrit.Huizenga@us.ibm.com
To: Rik van Riel <riel@conectiva.com.br>
Cc: Linus Torvalds <torvalds@transmeta.com>, Andi Kleen <ak@suse.de>,
Ingo Molnar <mingo@elte.hu>, Andrea Arcangeli <andrea@suse.de>,
Byron Stanoszek <gandalf@winds.org>,
MM mailing list <linux-mm@kvack.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler
Date: Mon, 09 Oct 2000 15:08:12 -0700 [thread overview]
Message-ID: <200010092208.e99M8CE14230@eng2.sequent.com> (raw)
In-Reply-To: Your message of Mon, 09 Oct 2000 18:05:57 -0300. <Pine.LNX.4.21.0010091759400.1562-100000@duckman.distro.conectiva>
At Sequent, we found that there are a small set of processes which are
"critical" to the system's operation in that they should not be killed
on swap shortage, memory shortage, etc. This included things like init,
potentially inetd, the swapper, page daemon, clusters heartbeat daemon,
and generally any core system service which had a user process component.
If there wasn't enough memory for those processes, or if those processes
weren't already responsible in their use of memory/resources, you were
already toast.
Anyway, there is/was an API in PTX to say (either from in-kernel or through
some user machinations) "I Am a System Process". Turns on a bit in the
proc struct (task struct) that made it exempt from death from a variety
of sources, e.g. OOM, generic user signals, portions of system shutdown,
etc.
Then, the code looking for things to kill simply skips those that are
intelligently marked, taking most of the decision making/policy making
out of the scheduler/memory manager.
gerrit
> On Mon, 9 Oct 2000, Linus Torvalds wrote:
> > On Mon, 9 Oct 2000, Andi Kleen wrote:
> > >
> > > netscape usually has child processes: the dns helper.
> >
> > Yeah.
> >
> > One thing we _can_ (and probably should do) is to do a per-user
> > memory pressure thing - we have easy access to the "struct
> > user_struct" (every process has a direct pointer to it), and it
> > should not be too bad to maintain a per-user "VM pressure"
> > counter.
> >
> > Then, instead of trying to use heuristics like "does this
> > process have children" etc, you'd have things like "is this user
> > a nasty user", which is a much more valid thing to do and can be
> > used to find people who fork tons of processes that are
> > mid-sized but use a lot of memory due to just being many..
>
> Sure we could do all of this, but does OOM really happen that
> often that we want to make the algorithm this complex ?
>
> The current algorithm seems to work quite well and is already
> at the limit of how complex I'd like to see it. Having a less
> complex OOM killer turned out to not work very well, but having
> a more complex one is - IMHO - probably overkill ...
>
> regards,
>
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
> -- Miguel de Icaza, UKUUG 2000
>
> http://www.conectiva.com/ http://www.surriel.com/
>
> --
> 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/
>
--
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/
next prev parent reply other threads:[~2000-10-09 22:08 UTC|newest]
Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-06 18:59 Rik van Riel
2000-10-06 20:19 ` Byron Stanoszek
2000-10-06 20:31 ` Rik van Riel
2000-10-09 10:12 ` Marco Colombo
2000-10-09 11:27 ` Byron Stanoszek
2000-10-09 16:26 ` Kurt Garloff
2000-10-09 18:29 ` Jamie Lokier
2000-10-09 17:27 ` Ingo Molnar
2000-10-09 17:25 ` Mark Hahn
2000-10-09 17:37 ` Ingo Molnar
2000-10-09 17:47 ` Ed Tomlinson
2000-10-09 18:01 ` Ingo Molnar
2000-10-09 18:14 ` Rik van Riel
2000-10-09 18:47 ` Ingo Molnar
2000-10-09 18:52 ` Rik van Riel
2000-10-09 19:27 ` Ingo Molnar
2000-10-09 19:38 ` Marco Colombo
2000-10-06 21:27 ` David Weinehall
2000-10-06 23:21 ` David Weinehall
2000-10-09 18:28 ` Andrea Arcangeli
2000-10-09 18:42 ` Ingo Molnar
2000-10-09 19:05 ` Andrea Arcangeli
2000-10-09 19:07 ` Rik van Riel
2000-10-09 19:42 ` Andrea Arcangeli
2000-10-09 20:06 ` Ingo Molnar
2000-10-09 20:06 ` Andi Kleen
2000-10-09 20:19 ` Ingo Molnar
2000-10-09 20:12 ` Rik van Riel
2000-10-09 20:24 ` Ingo Molnar
2000-10-09 20:18 ` Rik van Riel
2000-10-10 3:23 ` Philipp Rumpf
2000-10-09 20:38 ` James Sutherland
2000-10-09 20:40 ` Rik van Riel
2000-10-10 9:59 ` J.A. Sutherland
2000-10-09 20:44 ` Andrea Arcangeli
2000-10-09 21:52 ` Aaron Sethman
2000-10-09 21:54 ` Rik van Riel
2000-10-09 22:29 ` FORT David
2000-10-09 20:52 ` Linus Torvalds
2000-10-09 20:58 ` Andi Kleen
2000-10-09 21:21 ` Jim Gettys
2000-10-09 21:28 ` Alan Cox
2000-10-09 21:34 ` Andi Kleen
2000-10-09 21:38 ` Linus Torvalds
2000-10-09 21:39 ` Rik van Riel
2000-10-09 21:44 ` Linus Torvalds
2000-10-10 13:17 ` Marco Colombo
2000-10-09 21:44 ` Jim Gettys
2000-10-09 21:50 ` Linus Torvalds
2000-10-09 22:07 ` Jim Gettys
2000-10-09 23:13 ` Albert D. Cahalan
2000-10-09 23:16 ` Rik van Riel
2000-10-09 23:46 ` Jim Gettys
2000-10-10 9:46 ` Jamie Lokier
2000-10-10 14:41 ` Rogier Wolff
2000-10-10 17:28 ` Linus Torvalds
2000-10-09 21:51 ` Alan Cox
2000-10-09 21:40 ` Jim Gettys
2000-10-09 21:05 ` Rik van Riel
2000-10-09 22:08 ` Gerrit.Huizenga [this message]
2000-10-09 22:34 ` Byron Stanoszek
2000-10-09 22:57 ` Rik van Riel
2000-10-10 0:25 ` [RFC] New ideas for the " Byron Stanoszek
2000-10-09 20:11 ` [PATCH] VM fix for 2.4.0-test9 & " Andrea Arcangeli
2000-10-09 20:15 ` Rik van Riel
2000-10-09 20:40 ` Linus Torvalds
2000-10-09 20:47 ` Rik van Riel
2000-10-09 20:57 ` Ingo Molnar
2000-10-09 21:10 ` Peter Waltenberg
2000-10-09 22:25 ` Andrea Arcangeli
2000-10-09 22:59 ` Peter Waltenberg
2000-10-09 23:52 ` Andrea Arcangeli
2000-10-09 23:10 ` Rik van Riel
2000-10-09 21:10 ` Alan Cox
2000-10-09 21:25 ` Ingo Molnar
2000-10-09 21:26 ` Rik van Riel
2000-10-09 21:38 ` Ingo Molnar
2000-10-09 21:34 ` Rik van Riel
2000-10-10 9:09 ` john slee
2000-10-09 20:06 ` Rik van Riel
2000-10-09 20:18 ` Andrea Arcangeli
2000-10-10 3:29 ` Philipp Rumpf
2000-10-10 15:06 ` Rik van Riel
2000-10-10 15:24 ` Philipp Rumpf
2000-10-10 15:30 ` Rik van Riel
2000-10-10 15:37 ` Philipp Rumpf
2000-10-09 20:13 ` Ingo Molnar
2000-10-09 20:08 ` Rik van Riel
2000-10-09 20:22 ` Ingo Molnar
2000-10-09 20:28 ` David Ford
2000-10-09 20:34 ` Rik van Riel
2000-10-09 20:45 ` David Ford
2000-10-10 4:22 ` Andreas Dilger
2000-10-10 4:30 ` David Ford
2000-10-10 9:54 ` Jamie Lokier
2000-10-09 23:35 ` Ingo Oeser
2000-10-10 15:07 ` [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler) Ingo Oeser
2000-10-10 15:32 ` Rik van Riel
2000-10-10 16:11 ` Ingo Oeser
2000-10-10 18:57 ` Tom Rini
2000-10-10 20:58 ` Rik van Riel
2000-10-10 22:46 ` Tom Rini
2000-10-09 19:30 ` [PATCH] VM fix for 2.4.0-test9 & OOM handler David Ford
2000-10-09 19:58 ` Andrea Arcangeli
2000-10-09 20:14 ` David Ford
2000-10-09 20:05 ` Rik van Riel
2000-10-09 21:07 ` Alan Cox
2000-10-10 3:38 ` Philipp Rumpf
2000-10-10 14:07 ` Andrea Arcangeli
2000-10-09 18:07 Wagner, Dave
2000-10-09 20:27 ` James Sutherland
2000-10-09 19:06 Hubertus Franke/Watson/IBM
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=200010092208.e99M8CE14230@eng2.sequent.com \
--to=gerrit.huizenga@us.ibm.com \
--cc=ak@suse.de \
--cc=andrea@suse.de \
--cc=gandalf@winds.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=riel@conectiva.com.br \
--cc=torvalds@transmeta.com \
/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