From: Andries Brouwer <aebr@win.tue.nl>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: Andries Brouwer <aebr@win.tue.nl>, Jens Axboe <axboe@suse.de>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>, Andrea Arcangeli <andrea@suse.de>
Subject: Re: oom killer gone nuts
Date: Thu, 20 Jan 2005 19:15:55 +0100 [thread overview]
Message-ID: <20050120181555.GA11170@pclin040.win.tue.nl> (raw)
In-Reply-To: <20050120140033.GQ2240@logos.cnet>
On Thu, Jan 20, 2005 at 12:00:34PM -0200, Marcelo Tosatti wrote:
> On Thu, Jan 20, 2005 at 02:15:56PM +0100, Andries Brouwer wrote:
> > Yes, the fact that the oom-killer exists is a serious problem.
> > People work on trying to tune it, instead of just removing it.
> >
> > I am getting reports that also in overcommit mode 2 (no overcommit,
> > no oom-killer ever needed) processes are killed by the oom-killer
> > (on 2.6.10).
>
> Hi Andries,
>
> There is a user requirement for overcommit mode, you know.
>
> Saying "hey, there's no more overcommit mode in future v2.6 releases, you
> run out of memory and get -ENOMEM" is not really an option is it?
>
> You propose to remove the OOM killer and do what? Lockup solid?
Right now we have three overcommit modes.
They are specified by:
0: overcommit, but keep it reasonable (the current default)
1: overcommit, always say yes
2: keep track of all our obligations, do not overcommit
So, one has the right to expect that no OOM situation can occur
in overcommit mode 2. But in 2.6.10 it can. That is a bug.
The conclusion must be that bookkeeping is done incorrectly.
Perhaps also mode 0 is affected by that same bug.
Now you ask what I propose. There is no hurry worrying about that -
the first thing should be to fix the bookkeeping problem.
But assume that fixed. Then everybody can run in mode 2 and never
have any problems. That is what I do.
Yes, you say, but that is an inefficient use of memory. Perhaps.
That is the price I am willing to pay for the guarantee that my
processes are not killed at some random moment.
But if someone else does not do anything of importance and doesnt
care if his processes die at arbitrary moments if only things go
as fast as possible and use as much of his precious memory as possible,
then also for him overcommit mode 2 can be useful.
It is accompanied by the variable overcommit_ratio R - the amount
of memory that can be used is Swap + Memory*(R/100). Here R can be
larger than 100, so in overcommit mode 2 one can specify very precisely
what amount of overcommitment is considered acceptable.
Very few people run overcommit mode 2, and lots of things are
badly tested. It cannot become the default today.
But I would like to see it the default at some future moment.
Andries
next prev parent reply other threads:[~2005-01-20 18:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-20 12:34 Jens Axboe
2005-01-20 13:15 ` Andries Brouwer
2005-01-20 14:00 ` Marcelo Tosatti
2005-01-20 18:15 ` Andries Brouwer [this message]
2005-01-20 17:15 ` Andrea Arcangeli
2005-01-20 20:52 ` Andries Brouwer
2005-01-20 21:57 ` Chris Friesen
2005-01-20 23:27 ` Andrea Arcangeli
2005-01-21 7:42 ` Jens Axboe
2005-01-21 8:05 ` Andrea Arcangeli
2005-01-21 8:09 ` Jens Axboe
2005-01-21 8:41 ` Andrea Arcangeli
2005-01-21 8:46 ` Jens Axboe
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=20050120181555.GA11170@pclin040.win.tue.nl \
--to=aebr@win.tue.nl \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.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
all inboxes | Powered by JetHome®