From: Dave Jones <davej@redhat.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Roman Zippel <zippel@linux-m68k.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: oom kill oddness.
Date: Thu, 28 Sep 2006 20:22:12 -0400 [thread overview]
Message-ID: <20060929002212.GB19176@redhat.com> (raw)
In-Reply-To: <20060928171706.bee0c50b.akpm@osdl.org>
On Thu, Sep 28, 2006 at 05:17:06PM -0700, Andrew Morton wrote:
> On Fri, 29 Sep 2006 01:03:16 +0200 (CEST)
> Roman Zippel <zippel@linux-m68k.org> wrote:
>
> > Hi,
> >
> > On Wed, 27 Sep 2006, Dave Jones wrote:
> >
> > > So I have two boxes that are very similar.
> > > Both have 2GB of RAM & 1GB of swap space.
> > > One has a 2.8GHz CPU, the other a 2.93GHz CPU, both dualcore.
> > >
> > > The slower box survives a 'make -j bzImage' of a 2.6.18 kernel tree
> > > without incident. (Although it takes ~4 minutes longer than a -j2)
> > >
> > > The faster box goes absolutely nuts, oomkilling everything in sight,
> > > until eventually after about 10 minutes, the box locks up dead,
> > > and won't even respond to pings.
> > >
> > > Oh, the only other difference - the slower box has 1 disk, whereas the
> > > faster box has two in RAID0. I'm not surprised that stuff is getting
> > > oom-killed given the pathological scenario, but the fact that the
> > > box never recovered at all is a little odd. Does md lack some means
> > > of dealing with low memory scenarios ?
> >
> > I think I see the same thing on the other end on slow machines, here it
> > only takes a single compile job, which doesn't quite fit into memory and
> > another task (like top) which occasionally wakes up and tries to allocate
> > memory and then kills the compile job - that's very annoying.
> >
> > AFAICT the basic problem is that "did_some_progress" in __alloc_pages() is
> > rather local information, other processes can still make progress and keep
> > this process from making progress, which gets grumpy and starts killing.
> > What's happing here is that most memory is either mapped or in the swap
> > cache, so we have a race between processes trying to free memory from the
> > cache and processes mapping memory back into their address space.
>
> Kernel versions please, guys. There have been a lot of oom-killer changes
> post-2.6.18.
Sorry, I've been stuck on 2.6.18 as that's what we're shipping in FC6 soon.
Dave
next prev parent reply other threads:[~2006-09-29 0:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-27 20:54 oom kill oddness Dave Jones
2006-09-27 23:59 ` Andrew Morton
2006-09-28 23:03 ` Roman Zippel
2006-09-29 0:17 ` Andrew Morton
2006-09-29 0:22 ` Dave Jones [this message]
2006-09-29 0:57 ` Roman Zippel
2006-09-29 1:39 ` Nick Piggin
-- strict thread matches above, loose matches on Subject: below --
2006-09-29 20:03 Larry Woodman
2006-09-29 21:34 ` Dave Jones
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=20060929002212.GB19176@redhat.com \
--to=davej@redhat.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=zippel@linux-m68k.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.