Messages in this thread | | | Date | Tue, 10 Jul 2001 18:37:03 -0700 | From | Jun Sun <> | Subject | Re: 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 ...
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/
| |