From: David Konerding <dek_ml@konerding.com>
To: Guest section DW <dwguest@win.tue.nl>
Cc: "Dr. Michael Weller" <eowmob@exp-math.uni-essen.de>,
Andreas Dilger <adilger@turbolinux.com>,
Szabolcs Szakacsits <szaka@f-secure.com>,
Martin Dalecki <dalecki@evision-ventures.com>,
Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>,
Jonathan Morton <chromi@cyberspace.org>,
Rogier Wolff <R.E.Wolff@bitwizard.nl>,
linux-kernel@vger.kernel.org
Subject: Re: OOM killer???
Date: Thu, 29 Mar 2001 07:41:44 -0800 [thread overview]
Message-ID: <3AC357B8.72860494@konerding.com> (raw)
In-Reply-To: <200103282138.f2SLcT824292@webber.adilger.int> <Pine.A32.3.95.1010329111147.63156A-100000@werner.exp-math.uni-essen.de> <20010329130154.A8701@win.tue.nl>
I would tend to agree, I'm not a fan of the OOM killer's behavior. The OOM is forced
because of the policy of overcommitting of memory. The reason for that policy is
based on an observation:
many programs allocate far more memory than they ever use, and most people don't want
their program to crash just because it malloc()s memory it isn't going to use.
Having to activate the pages for memory that never gets used feels wasteful to some
people. On the other hand, having my two-week-running scientific app killed because
it did a whole bunch of disk reads that fill up 600MB of my 768MB RAM, then tried to
allocate a whole bunch more memory (that it *will* use) is obviously a fault of the
OOM killer policy. At the very least the entire disk cache, or a goodly portion of
it, should be drained before ever invoking the OOM. I'm more than glad to pay the
performance hit of no disk buffers for the privilege of having my job finish.
Now, if you're going to implement OOM, when it is absolutely necessary, at the very
least, move the policy implementation out of the kernel. One of the general
philosophies of Linux has been to move policy out of the kernel. In this case, you'd
just have a root owned process with locked pages that can't be pre-empted, which
implemented the policy. You'll never come up with an OOM policy that will fit
everybody's needs unless it can be tuned for particular system's usage, and it's
going to be far easier to come up with that policy if it's not in the kernel.
Guest section DW wrote:
> Two things are wrong.
> 1. Linux has an OOM killer.
> 2. The OOM killer has a bad behaviour.
>
> Presently, with the proper kind of load, one can see a process killed
> by OOM almost daily. That is totally unacceptable.
> People are working on refining the algorithm so that blatant idiocies
> where processes are killed while there is plenty of resources
> are avoided. Good. Suppose it done. Then one thing is wrong.
>
> 1. Linux has an OOM killer.
>
> A system with an OOM killer is unreliable. Linux must have a reliable
> mode of operation, and that must be the default mode.
>
> Now you assume that adding SIGDANGER would make people happy.
> But it would be a rather unimportant addition.
> It might help in some cases, but it falls in the category
> of improving the OOM killer a little.
>
> People will be happy when Linux is reliable by default.
>
> Andries
>
> [Never use planes where the company's engineers spend their
> time designing algorithms for selecting which passenger
> must be thrown out when the plane is overloaded.]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2001-03-29 15:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200103282138.f2SLcT824292@webber.adilger.int>
2001-03-29 9:29 ` OOM killer??? Dr. Michael Weller
2001-03-29 11:01 ` Guest section DW
2001-03-29 12:02 ` Sean Hunter
2001-03-29 12:57 ` Guest section DW
2001-03-29 15:41 ` David Konerding [this message]
2001-03-29 17:52 ` David Lang
2001-03-30 2:26 ` Michael Peddemors
2001-03-30 14:48 ` J. Scott Kasten
2001-03-29 17:21 ` Stephen Satchell
2001-03-29 13:53 ` Szabolcs Szakacsits
2001-03-29 15:01 ` Dr. Michael Weller
2001-03-29 16:29 ` Szabolcs Szakacsits
2001-03-29 16:51 ` Szabolcs Szakacsits
2001-03-29 19:20 Jesse Pollard
-- strict thread matches above, loose matches on Subject: below --
2001-03-29 16:22 Jesse Pollard
2001-03-27 10:59 Rogier Wolff
2001-03-27 12:14 ` Jonathan Morton
2001-03-27 13:24 ` Martin Dalecki
2001-03-27 15:31 ` Jonathan Lundell
2001-03-27 18:08 ` Ingo Oeser
2001-03-27 19:07 ` Martin Dalecki
2001-03-27 19:55 ` Andreas Dilger
2001-03-27 21:13 ` Andreas Rogge
2001-03-27 18:37 ` Jonathan Morton
2001-03-27 13:57 ` Jonathan Morton
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=3AC357B8.72860494@konerding.com \
--to=dek_ml@konerding.com \
--cc=R.E.Wolff@bitwizard.nl \
--cc=adilger@turbolinux.com \
--cc=chromi@cyberspace.org \
--cc=dalecki@evision-ventures.com \
--cc=dwguest@win.tue.nl \
--cc=eowmob@exp-math.uni-essen.de \
--cc=ingo.oeser@informatik.tu-chemnitz.de \
--cc=linux-kernel@vger.kernel.org \
--cc=szaka@f-secure.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