From: Dave Jones <davej@redhat.com>
To: Andrew Morton <akpm@osdl.org>
Cc: "Martin J. Bligh" <mbligh@mbligh.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andy Whitcroft <apw@shadowen.org>,
Larry Woodman <lwoodman@redhat.com>
Subject: Re: OOM killer firing on 2.6.18 and later during LTP runs
Date: Sun, 26 Nov 2006 02:25:38 -0500 [thread overview]
Message-ID: <20061126072538.GA5223@redhat.com> (raw)
In-Reply-To: <20061125231153.5cbd4581.akpm@osdl.org>
On Sat, Nov 25, 2006 at 11:11:53PM -0800, Andrew Morton wrote:
> On Sat, 25 Nov 2006 22:00:45 -0500
> Dave Jones <davej@redhat.com> wrote:
>
> > On Sat, Nov 25, 2006 at 01:28:28PM -0800, Andrew Morton wrote:
> > > On Sat, 25 Nov 2006 13:03:45 -0800
> > > "Martin J. Bligh" <mbligh@mbligh.org> wrote:
> > >
> > > > On 2.6.18-rc7 and later during LTP:
> > > > http://test.kernel.org/abat/48393/debug/console.log
> > >
> > > The traces are a bit confusing, but I don't actually see anything wrong
> > > there. The machine has used up all swap, has used up all memory and has
> > > correctly gone and killed things. After that, there's free memory again.
> >
> > We covered this a month or two back. For RHEL5, we've ended up
> > reintroducing the oom killer prevention logic that we had up until
> > circa 2.6.10. It seemed that there exist circumstances where
> > given a little more time, some memory hogging apps will run to completion
> > allowing other allocators to succeed instead of being killed.
>
> I _think_ what you're describing here is a false-positive oom-killing? But
> Martin appears to be hitting a genuine oom.
what we saw during the rhel5 testing was that yes, the machine _was_ OOM
*temporarily*, but if instead of killing the task trying to allocate, we
postponed the killing a few times, it would give other tasks the opportunity
to complete writeout, or free up memory some other way, allowing the
allocating process to succeed shortly afterwards.
> But it does appear that some changes are needed, because lots of things got
> oom-killed.
>
> I think. Maybe not - there's no timestamping in those logs and it is of
> course possible that we're seeing unrelated ooms which happened a long time
> apart.
Maybe, but it does sound spookily familiar.
The last time Larry's patch got floated to lkml it was met with
"Ah!, but we have new oom killer changes in -git which might solve this".
We tried them. They didn't.
Dave
--
http://www.codemonkey.org.uk
next prev parent reply other threads:[~2006-11-26 7:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-25 21:03 OOM killer firing on 2.6.18 and later during LTP runs Martin J. Bligh
2006-11-25 21:28 ` Andrew Morton
2006-11-25 21:35 ` Martin J. Bligh
2006-11-25 22:08 ` Andrew Morton
2006-11-26 3:00 ` Dave Jones
2006-11-26 7:11 ` Andrew Morton
2006-11-26 7:25 ` Dave Jones [this message]
2006-11-26 7:30 ` Andrew Morton
2006-11-26 11:38 ` Andy Whitcroft
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=20061126072538.GA5223@redhat.com \
--to=davej@redhat.com \
--cc=akpm@osdl.org \
--cc=apw@shadowen.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lwoodman@redhat.com \
--cc=mbligh@mbligh.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.