Re: 2.5.53-mm3: xmms: page allocation failure. order:5, mode:0x20

Andrew Morton (akpm@digeo.com)
Sun, 29 Dec 2002 17:06:54 -0800


Alan Cox wrote:
>
> On Sun, 2002-12-29 at 20:42, Andrew Morton wrote:
> > gack. Someone is requesting 128k of memory with GFP_ATOMIC. It fell
> > afoul of the reduced memory reserves. It deserved to.
>
> ISA sound I/O. And yes it really does want the 128K if it can get it on
> a slower box. It will try 128/64/32/.. so it gets less if there isnt any
> DMA RAM around. All the sound works this way because few bits of sound
> hardware, even in the PCI world, support scatter gather.
>
> If the VM can't deal with it - we need to fix the VM.

It'll tend to usually work because GFP_KERNEL allocations prefer to
not dip into the DMA region.

> All these allocations are blocking and can wait a long time.

But it's not! dma_alloc_coherent() is using GFP_ATOMIC|__GFP_DMA.

Now, if we can fix the caller to use

__GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_FS | __GFP_DMA

then that at least will allow page reclaim.

Then we can remove this restriction in __alloc_pages():

/*
* Don't let big-order allocations loop. Yield for kswapd, try again.
*/
if (order <= 3) {
yield();
goto rebalance;
}

and all will be well.

dma_alloc_coherent() should be fixed to take a gfp_mask, and callers
should be updated.

As for permitting direct page reclaim for higher-order allocations: I
just don't know - it's from before my time. Perhaps the VM will livelock.
-
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/