From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Andries Brouwer <aebr@win.tue.nl>
Cc: 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 12:00:34 -0200 [thread overview]
Message-ID: <20050120140033.GQ2240@logos.cnet> (raw)
In-Reply-To: <20050120131556.GC10457@pclin040.win.tue.nl>
On Thu, Jan 20, 2005 at 02:15:56PM +0100, Andries Brouwer wrote:
> On Thu, Jan 20, 2005 at 01:34:06PM +0100, Jens Axboe wrote:
>
> > Using current BK on my x86-64 workstation, it went completely nuts today
> > killing tasks left and right with oodles of free memory available.
>
> 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?
It is _WAY_ off right now: look at the amount of free pages:
DMA free:4536kB min:60kB low:72kB high:88kB active:0kB inactive:0kB present:16384kB pages_scanned:0 all_unreclaimable? no
protections[]: 0 0 0
Normal free:524648kB min:4028kB low:5032kB high:6040kB active:76508kB inactive:81760kB present:1031360kB pages_scanned:0 all_unreclaimable? no
protections[]: 0 0 0
HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
protections[]: 0 0 0
DMA: 556*4kB 155*8kB 65*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4536kB
Normal: 29800*4kB 25115*8kB 6953*16kB 1251*32kB 326*64kB 103*128kB 31*256kB 12*512kB 3*1024kB 1*2048kB 0*4096kB = 524648kB
HighMem: empty
v2.4 gets it pretty much right for most cases, and its obviously screwed up right now in v2.6.
Andrea/Thomas were working on getting it fixed ??
next prev parent reply other threads:[~2005-01-20 17:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-20 12:34 oom killer gone nuts Jens Axboe
2005-01-20 13:15 ` Andries Brouwer
2005-01-20 14:00 ` Marcelo Tosatti [this message]
2005-01-20 18:15 ` Andries Brouwer
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=20050120140033.GQ2240@logos.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=aebr@win.tue.nl \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=axboe@suse.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.