From: Doug Dumitru <doug@easyco.com>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: "David S. Miller" <davem@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: Hard Hang with __alloc_pages: 0-order allocation failed (gfp=0x20/1) - Not out of memory
Date: Wed, 26 May 2004 11:59:24 -0700 [thread overview]
Message-ID: <40B4E90C.6000202@easyco.com> (raw)
In-Reply-To: <20040526125921.GJ6439@logos.cnet>
Marcelo Tosatti wrote:
> On Tue, May 25, 2004 at 04:12:12PM -0700, David S. Miller wrote:
>
>>On Tue, 25 May 2004 15:26:30 -0700
>>Doug Dumitru <doug@easyco.com> wrote:
>>
>>
>>>This is the original trap dump from a __page_alloc error
>>>
>>>__alloc_pages: 0-order allocation failed (gfp=0x20/1)
>>
>>0x20 means GFP_ATOMIC which means it's fine to fail
>>and e1000 is doing nothing wrong. GFP_ATOMIC in interrupts
>>is a fine condition.
>
>
> Yeap, but the crash is not a fine condition... I suspect
> what can be happening is extreme gigabit traffic resulting in
> memory shortage.
>
> Doug said the load average is really high. Doug, you're not
> using NAPI, right? Can you try it?
Prior to the __page_alloc hang, the loadavg shoots way up, so something
is spinning, but it is hard to tell what. This has persisted for as
long as 8-10 minutes on one hang, although it is usually shorter (1-2
minutes). One of my concerns is that the e1000 issue might only be a
symptom of the page tables getting clobbered by something else. I have
been trying to get the system to hang during more "controlled" usage,
but have been unable to. I have even run tsl (telnet scripting
language) scripts to logon 250 processes and beat the CPU and disk up,
creating and destroying processes along the way. I was able to drive
loadavg > 50 and LowFree to < 5000K, but could never create a hang. I
suspect that I might need truely "random" inbound traffic to find the
bug (but this is a guess).
In terms of network traffic, the system is busy, but not obnoxiously so.
The load on the server is primarily terminal traffic from about 200
"real humans", so there are a lot of small, random packets. In terms of
network bandwidth, it is not all that bad, maybe 2-3 megabits (a guess).
The arp table is reasonably big (> 200 entries) but this is not that
bad either. I have not looked for arp storms or other network anomolies
on the LAN. The system is on a local LAN and gets no internet traffic.
I am unfamiliar with NAPI, so I have not tried it.
On another topic, I am trying to build a 2.4.26 kernel that reserves
more LowFree. The mm/page_alloc.c file describes a boot parameter
called "lower_zone_reserve" that should tune this. Unfortunately, this
parameter seems to be read after the zone tables are initialized (which
is probably a bug).
--
--------------------------------------------------------------------
Doug Dumitru 800-470-2756 (610-237-2000)
EasyCo LLC doug@easyco.com http://easyco.com
--------------------------------------------------------------------
next prev parent reply other threads:[~2004-05-26 18:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-25 22:26 Hard Hang with __alloc_pages: 0-order allocation failed (gfp=0x20/1) - Not out of memory Doug Dumitru
2004-05-25 23:12 ` David S. Miller
2004-05-26 12:59 ` Marcelo Tosatti
2004-05-26 18:59 ` Doug Dumitru [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-05-26 1:22 (Found?) " Roger Larsson
2004-05-26 19:58 ` Roger Larsson
2004-05-25 22:17 Doug Dumitru
2004-05-25 21:20 Feldman, Scott
2004-05-25 21:47 ` David S. Miller
2004-05-25 22:53 ` Marcelo Tosatti
2004-05-25 23:39 ` Marcelo Tosatti
2004-05-25 22:53 ` Marcelo Tosatti
2004-05-24 3:08 Doug Dumitru
2004-05-25 19:02 ` Marcelo Tosatti
2004-05-23 21:54 Doug Dumitru
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=40B4E90C.6000202@easyco.com \
--to=doug@easyco.com \
--cc=davem@redhat.com \
--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 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.