It's an atomic allocation, the driver is supposed to be able to handle this,
and it does since you report that the burn just runs slowly, it does not
stop. There is way too much in cache:
> total: used: free: shared: buffers: cached:
> Mem: 1053675520 1047502848 6172672 0 20930560 939307008
> Swap: 271392768 15880192 255512576
This is causing the high order allocation failures - with only a small
fraction of memory free the chances of none of it being in contiguous,
aligned 8 page units rises dramatically. It's likely the kprint that is
slowing you down, you could check this by commenting it out (page_alloc.c,
near the end of __alloc_pages).
Do you have the same problem on 2.4.8, but not in 2.4.7?
-- Daniel - 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/