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/
This archive was generated by hypermail 2b29 : Tue Dec 31 2002 - 22:00:15 EST