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