Re: memory alloc failuer : __alloc_pages: 1-order allocation failed.

[Jun Sun <jsun@mvista.com>]

Just found more about this problem....

Jun Sun wrote:
> 
> I am running 2.4.2 on a linux/mips box, with 32MB system RAM (no swap).  When
> I run a stress test, I will hit memory allocation failure:
> 
> __alloc_pages: 1-order allocation failed.
> IP: queue_glue: no memory for gluing queue 8108cce0
> 
> However, I traced the system and found several questions.
> 
> First, free reports enough free memory and LOTS of cache memory.  See below.
> Should'nt Linux free cache memory to satisfy this request?
> 
>              total       used       free     shared    buffers     cached
> Mem:         30052      29296        756          0          0      16928
> -/+ buffers/cache:      12368      17684
> Swap:            0          0          0
>

The memory allocation is invoked with GFP_ATOMIC, and thus does not free up
the cached pages.  (Why? because it is invoked from interrupt context?)
 
> I used kgdb and dig into rmqueue() in mm/page_alloc.c file.  There are two
> zones in this system.  They do have many free pages but none of free blocks
> seem to be big enough for the 2-page request.  Does this make sense?  Why does
> kernel end up with so many fragmented 1-page free areas?  See the kgdb output
> below.
>

Shouldn't some kernel daemon try to maintain a "reasonable" free_area,
including a 2-page block?  It seems like in my case the daemon failed to do
the job.  (Which daemon is it? kflushd?)  What is the condition to kick start
this daemon?  I suppose in my case the total free page count is still high,
which may fail to start the daemon.

In the end, allocating memory from interrupt context for re-assembling IP
packet does not sound pretty either ...


Jun