[lkml]   [2001]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: memory alloc failuer : __alloc_pages: 1-order allocation failed.

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 ...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:56    [W:0.043 / U:0.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site