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

[Andrew Morton <akpm@digeo.com>]

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.