From: "Phil Oester" <kernel@theoesters.com>
To: "'Stephan von Krawczynski'" <skraw@ithnet.com>
Cc: <nknight@pocketinet.com>, <linux-kernel@vger.kernel.org>
Subject: RE: 1gb RAM + 1gb SWAP + make -j bzImage = OOM
Date: Sun, 6 Jan 2002 22:22:16 -0800
Message-ID: <000101c19743$a6dc4120$6400a8c0@philxp>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20020105161727.18f04fc3.skraw@ithnet.com>
Importance: Normal
Sender: linux-kernel-owner@vger.kernel.org

I've rerun this test a number of times, and cannot reliably reproduce
the OOM - though it still does OOM occasionally.  It never OOM's right
after a bootup - usually the greatest chance of OOM is after 2 or 3
consecutive runs without a reboot.  Once it even froze the box and
required a powercycle.

I'm surprised you cannot OOM with 1gb RAM/256MB swap, as sometimes I'm
over 900MB in swap - did you try consecutive runs, or just once and then
reboot between each run?

On a side note, there seems to be some debate as to whether this is a
valid test.  The detractors primarily claim that 'make -j' just
overloads the machine with too many processes and therefore is setting
it up to fail.  My position has always been that the kernel
_should_not_OOM_ under this test due to the ~2gb of ~RAM being thrown at
it.  It may die for any number of other reasons, but OOM shouldn't be
one of them.  In other words, either the OOM killer may be too
aggressive here, or the kernel isn't reclaiming inactive RAM under heavy
load.

Haven't yet tried Martin's patch - though since I can't reliably produce
the OOM, testing it wouldn't help much.

-Phil Oester


-----Original Message-----
From: Stephan von Krawczynski [mailto:skraw@ithnet.com] 
Sent: Saturday, January 05, 2002 7:17 AM
To: Phil Oester
Cc: nknight@pocketinet.com; linux-kernel@vger.kernel.org
Subject: Re: 1gb RAM + 1gb SWAP + make -j bzImage = OOM

I guess this testcase is somewhat driving in the direction of Martins
test with
some setis running, meaning it has a lot of standard processes that need
files
and try to work out something. Can you try Martins patch at your side,
redo the
-j story and give us a result? I attached it for an easy go :-)

Thanks,
Stephan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/