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
