From: jfm2@club-internet.fr
To: jas88@cam.ac.uk
Cc: ingo.oeser@informatik.tu-chemnitz.de, riel@conectiva.com.br,
torvalds@transmeta.com, linux-mm@kvack.org
Subject: Re: Discussion on my OOM killer API
Date: Sat, 28 Oct 2000 00:12:59 +0200 (CEST) [thread overview]
Message-ID: <20001027221259.C0ED4F42C@agnes.fremen.dune> (raw)
In-Reply-To: <Pine.LNX.4.10.10010271832020.13084-100000@dax.joh.cam.ac.uk> (message from James Sutherland on Fri, 27 Oct 2000 18:36:13 +0100 (BST))
>
> On Fri, 27 Oct 2000, Ingo Oeser wrote:
>
> > On Fri, Oct 27, 2000 at 12:58:44AM +0100, James Sutherland wrote:
> > > Which begs the question, where did the userspace OOM policy daemon go? It,
> > > coupled with Rik's simple in-kernel last-ditch handler, should cover most
> > > eventualities without the need for nasty kernel kludges.
> >
> > If I do the full blown variant of my patch:
> >
> > echo "my-kewl-oom-killer" >/proc/sys/vm/oom_handler
> >
> > will try to load the module with this name for a new one and
> > uninstall the old one.
>
> EBADIDEA. The kernel's OOM killer is a last ditch "something's going to
> die - who's first?" - adding extra bloat like this is BAD.
>
> Policy should be decided user-side, and should prevent the kernel-side
> killer EVER triggering.
>
Only problem is that your user side process will have been pushed out
of memory by netcape and that in this kind of situations it will take
a looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong
time to be recalled from swap and it being able to kill anything.
Well before it comes back netscape will have eaten all remaining
memory so kernel will have to decide by itself.
Only solution is to allow the OOM never to be swapped but you also
need all libraries to remain in memory or have the kernel check OOM is
statically linked. However this user space OOM will then have a
sigificantly memory larger footprint than a kernel one and don't
forget it cannot be swapped.
> > The original idea was an simple "I install a module and lock it
> > into memory" approach[1] for kernel hackers, which is _really_
> > easy to to and flexibility for nothing[2].
> >
> > If the Rik and Linus prefer the user-accessable variant via
> > /proc, I'll happily implement this.
> >
> > I just intended to solve a "religious" discussion via code
> > instead of words ;-)
>
> I was planning to implement a user-side OOM killer myself - perhaps we
> could split the work, you do kernel-side, I'll do the userspace bits?
>
Hhere is an heuristic who tends to work well ;-)
if (short_on_memory == TRUE ) {
kill_all_copies_of_netscape()
}
--
Jean Francois Martinez
--
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-27 22:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20001019122331.H840@nightmaster.csn.tu-chemnitz.de>
2000-10-19 17:02 ` Rik van Riel
2000-10-26 20:47 ` Linus Torvalds
2000-10-26 21:16 ` Rik van Riel
2000-10-26 22:33 ` Mark Hahn
2000-10-26 23:58 ` James Sutherland
2000-10-27 0:10 ` Linus Torvalds
2000-10-27 6:46 ` James Sutherland
2000-10-27 7:39 ` Gábor Lénárt
2000-10-27 13:54 ` James Sutherland
2000-10-27 17:10 ` Ingo Oeser
2000-10-27 17:36 ` James Sutherland
2000-10-27 22:12 ` jfm2 [this message]
2000-10-27 22:11 ` James Sutherland
2000-10-27 22:43 ` jfm2
2000-10-27 22:51 ` James Sutherland
2000-10-28 4:48 ` Jeremy Fitzhardinge
2000-10-28 7:29 ` James Sutherland
2000-10-30 9:02 ` G?bor L?n?rt
2000-10-30 9:41 ` James Sutherland
2000-10-30 9:53 ` G?bor L?n?rt
2000-10-30 12:18 ` J.A. Sutherland
2000-10-29 19:30 ` Ingo Oeser
2000-10-29 20:41 ` James Sutherland
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=20001027221259.C0ED4F42C@agnes.fremen.dune \
--to=jfm2@club-internet.fr \
--cc=ingo.oeser@informatik.tu-chemnitz.de \
--cc=jas88@cam.ac.uk \
--cc=linux-mm@kvack.org \
--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