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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox