From: Andreas Dilger <adilger@turbolinux.com>
To: david+validemail@kalifornia.com
Cc: Rik van Riel <riel@conectiva.com.br>,
mingo@elte.hu, Andrea Arcangeli <andrea@suse.de>,
Byron Stanoszek <gandalf@winds.org>,
Linus Torvalds <torvalds@transmeta.com>,
MM mailing list <linux-mm@kvack.org>,
linux-kernel@vger.kernel.org, jg@pa.dec.com,
alan@lxorguk.ukuu.org.uk, acahalan@cs.uml.edu,
Gerrit.Huizenga@us.ibm.com
Subject: Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler
Date: Mon, 9 Oct 2000 22:22:42 -0600 (MDT) [thread overview]
Message-ID: <200010100422.e9A4Mg722840@webber.adilger.net> (raw)
In-Reply-To: <39E22E80.75819894@kalifornia.com> "from David Ford at Oct 9, 2000 01:45:53 pm"
> Rik van Riel wrote:
> > > How about SIGTERM a bit before SIGKILL then re-evaluate the OOM
> > > N usecs later?
> >
> > And run the risk of having to kill /another/ process as well ?
> >
> > I really don't know if that would be a wise thing to do
> > (but feel free to do some tests to see if your idea would
> > work ... I'd love to hear some test results with your idea).
David Ford writes:
> I was thinking (dangerous) about an urgent v.s. critical OOM. urgent could
> trigger a SIGTERM which would give advance notice to the offending process.
> I don't think we have a signal method of notifying processes when resources
> are critically low, feel free to correct me.
>
> Is there a signal that -might- be used for this?
Albert D. Cahalan wrote:
> X, and any other big friendly processes, could participate in
> memory balancing operations. X could be made to clean out a
> font cache when the kernel signals that memory is low. When
> the situation becomes serious, X could just mmap /dev/zero over
> top of the background image.
>
> Netscape could even be hacked to dump old junk... or if it is
> just too leaky, it could exec itself to fix the problem.
Gerrit Huizenga wrote:
> 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.
On AIX there is a signal called SIGDANGER, which is basically what you
are looking for. By default it is ignored, but for processes that care
(e.g. init, X, whatever) they can register a SIGDANGER handler. At an
"urgent" (as oposed to "critical") OOM situation, all processes get a
SIGDANGER sent to them. Most will ignore it, but ones with handlers
can free caches, try to do a clean shutdown, whatever. Any process with
a SIGDANGER handler get a reduction of "badness" (as the OOM killer calls
it) when looking for processes to kill.
Having a SIGDANGER handler is good for 2 reasons:
1) Lets processes know when memory is short so they can free needless cache.
2) Mark process with a SIGDANGER handler as "more important" than those
without. Most people won't care about this, but init, and X, and
long-running simulations might.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
--
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-10 4:22 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
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 [this message]
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=200010100422.e9A4Mg722840@webber.adilger.net \
--to=adilger@turbolinux.com \
--cc=Gerrit.Huizenga@us.ibm.com \
--cc=acahalan@cs.uml.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andrea@suse.de \
--cc=david+validemail@kalifornia.com \
--cc=gandalf@winds.org \
--cc=jg@pa.dec.com \
--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