page allocation failure & sk98lin
Hello all,
I found a few references to similar problems in the list but no indications of whether this has been fixed or can be avoided.
I'm using 2.6.8.1 and the patch: sk98lin_v7.04_2.6.8_patch. This happens
when receiving data fast on the GigE card (about 600Mbps) and writing
on disk. It seems to happen after writing 1 GB to disk (1024 MB) but I can't correlate that very reliably.
I would appreciate any information pointing me to a fix or explanation.
Thank you!
-Serban
swapper: page allocation failure. order:0, mode:0x20
[<c013ec91>] __alloc_pages+0x2bf/0x2dd [<c013ecc7>] __get_free_pages+0x18/0x24 [<c0141b8a>] kmem_getpages+0x20/0xc9 [<c01427b3>] cache_grow+0xae/0x156 [<c0142a2f>] cache_alloc_refill+0x1d4/0x211 [<c0142e50>] __kmalloc+0x79/0x8c [<c027bd63>] alloc_skb+0x35/0xc9 [<f8b7cbc4>] AllocAndMapRxBuffer+0x1e/0xc1 [sk98lin] [<f8b7af5a>] GiveRxBufferToHw+0x14e/0x3f4 [sk98lin] [<f8b7b274>] FillReceiveTableYukon2+0x74/0x7c [sk98lin] [<f8b7c467>] HandleStatusLEs+0xd4/0x30e [sk98lin] [<f8b7aa5f>] SkY2Poll+0x33/0xed [sk98lin] [<c02817cf>] net_rx_action+0x70/0xf2 [<c0124fa2>] __do_softirq+0x52/0xab [<c0125028>] do_softirq+0x2d/0x2f [<c0107f9e>] do_IRQ+0xfb/0x112 [<c01066d8>] common_interrupt+0x18/0x20 [<c01040da>] mwait_idle+0x25/0x4a [<c01040a7>] cpu_idle+0x2e/0x3c [<c01216d5>] call_console_drivers+0xce/0xeb [<c01bb1b8>] vscnprintf+0x14/0x21 [<c012191b>] printk+0x152/0x165
Quoted 6 lines · Serban Simu
Hello all,
I found a few references to similar problems in the list but no indications of whether this has been fixed or can be avoided.
I'm using 2.6.8.1 and the patch: sk98lin_v7.04_2.6.8_patch. This happens when receiving data fast on the GigE card (about 600Mbps) and writing on disk. It seems to happen after writing 1 GB to disk (1024 MB) but I can't correlate that very reliably.
Quoted 7 lines
I would appreciate any information pointing me to a fix or explanation.
Thank you!
-Serban
swapper: page allocation failure. order:0, mode:0x20
The messages should be basically harmless and can't be completely avoided.
That said, -mm kernels have patches to fix up numerous problems with the page allocator which have a good chance of fixing your problems.
Thank you, Nick. Just wanted to mention that while I understand that we recover from this allocation failure (and also I don't mind the stack printouts), about 20% of my incoming network traffic (600-700 Mbps) seems to be dropped in the process. Does the memory manager have to spend a considerable amount of time to recover?
I will have a look at the -mm fixes, thanks for the idea.
-Serban
Quoted 28 lines · Nick Piggin
Quoted 6 lines · Serban Simu
Hello all,
I found a few references to similar problems in the list but no indications of whether this has been fixed or can be avoided.
I'm using 2.6.8.1 and the patch: sk98lin_v7.04_2.6.8_patch. This happens when receiving data fast on the GigE card (about 600Mbps) and writing on disk. It seems to happen after writing 1 GB to disk (1024 MB) but I can't correlate that very reliably.
Quoted 7 lines
I would appreciate any information pointing me to a fix or explanation.
Thank you!
-Serban
swapper: page allocation failure. order:0, mode:0x20
The messages should be basically harmless and can't be completely avoided.
That said, -mm kernels have patches to fix up numerous problems with the page allocator which have a good chance of fixing your problems.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 1 line · Serban Simu
Thank you, Nick. Just wanted to mention that while I understand that we recover from this allocation failure (and also I don't mind the stack printouts), about 20% of my incoming network traffic (600-700 Mbps) seems to be dropped in the process.
Yeah that is expected - so I guess it isn't exactly 'harmless' if performance is critical.
Quoted 4 lines
Does the memory manager have to spend a considerable amount of time to recover?
I will have a look at the -mm fixes, thanks for the idea.
The relevant patch is this one which is now merged into 2.6.
It would be nice if you can test that. It will give GFP_ATOMIC allocators a larger buffer between starting memory reclaim, and failing their allocations.
However if it is a production system and you can't test patches, Marcelo pointed out that you should be able to work around the problem by increasing /proc/sys/vm/min_free_kbytes. Then maybe you could try 2.6.9 with min_free_kbytes back to its default setting :)