public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Peddemors <michael@linuxmagic.com>
To: David Konerding <dek_ml@konerding.com>
Cc: Guest section DW <dwguest@win.tue.nl>, linux-kernel@vger.kernel.org
Subject: Re: OOM killer???
Date: 29 Mar 2001 18:26:32 -0800	[thread overview]
Message-ID: <20010330024815Z130448-406+5643@vger.kernel.org> (raw)
In-Reply-To: <3AC357B8.72860494@konerding.com>
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>  <3AC357B8.72860494@konerding.com>

Looking over the last few weeks of postings, there are just WAY to many
conflicting ways that people want the OOM to work..  Although an
incredible amount of good work has gone into this, people are definetely
not happy about the benifits of OOM ...  About 10 different approaches
are being made to change the rule based systems pertaining to WHEN the
OOM will fire, but in the end, still not everyone will be happy..

The old way of having a machien crash when you asked too much of it
seemed acceptable.. People then either chose to run the mem hog, and
upgrade their boxes, or they stopped running the memhog.

Maybe its time to hear from on high whether OOM capability outweighs the
problems that seem to be associated with it?

Either that or we should be able to allow the end user/and the distros
to decide what gets killed by OOM.

Some people might like to just say to heck with it, and not let anything
get killed, while others may just want to protect certain things.. 

Speaking completely where I don't belong, and don't know enough about..
Just a thought, can we come up with a new form of execute bit that would
define whether OOM should affect the process?  Then the app can be made
to be killable if not as root etc...  As well as being applied simply at
a per application basis, because we KNOW that not all applications will
ever be completely system friendly..
There will always be useful programs that might not fit into a OOM model
well.

Linus has been notably quite of late about this issue, given the amount
of contention on this issue..

On 29 Mar 2001 07:41:44 -0800, David Konerding wrote:

> 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.

-- 
"Catch the Magic of Linux..."
--------------------------------------------------------
Michael Peddemors - Senior Consultant
LinuxAdministration - Internet Services
NetworkServices - Programming - Security
WizardInternet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
--------------------------------------------------------
(604)589-0037 Beautiful British Columbia, Canada


  parent reply	other threads:[~2001-03-30  2:48 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
2001-03-29 17:52       ` David Lang
2001-03-30  2:26       ` Michael Peddemors [this message]
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=20010330024815Z130448-406+5643@vger.kernel.org \
    --to=michael@linuxmagic.com \
    --cc=dek_ml@konerding.com \
    --cc=dwguest@win.tue.nl \
    --cc=linux-kernel@vger.kernel.org \
    /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