Messages in this thread | | | Date | Tue, 24 Feb 2004 17:25:05 -0800 | From | Andrew Morton <> | Subject | Re: page allocation failure. order:3, mode:0x20 |
| |
"Marco d'Itri" <md@Linux.IT> wrote: > > Linux attila 2.6.3 #1 Fri Feb 20 02:12:34 CET 2004 ppc GNU/Linux > > (Linus tree.) > > kernel: tinyproxy: page allocation failure. order:3, mode:0x20 > kernel: Call trace: > kernel: [c00097e8] dump_stack+0x18/0x28 > kernel: [c0037fd8] __alloc_pages+0x31c/0x364 > kernel: [c003804c] __get_free_pages+0x2c/0x74 > kernel: [c003b14c] cache_grow+0x94/0x328 > kernel: [c003b5a0] cache_alloc_refill+0x1c0/0x25c > kernel: [c003b9ac] __kmalloc+0xa8/0xb4 > kernel: [c0167dc8] alloc_skb+0x4c/0xe0 > kernel: [c0127004] loopback_xmit+0x100/0x110 > kernel: [c016d0c0] dev_queue_xmit+0xcc/0x248 > kernel: [c0184464] ip_finish_output+0x124/0x26c > kernel: [c018698c] dst_output+0x28/0x5c > kernel: [c01784c8] nf_hook_slow+0xf0/0x14c > kernel: [c0184c50] ip_queue_xmit+0x408/0x520 > kernel: [c01960b4] tcp_transmit_skb+0x3e4/0x5e4 > kernel: tinyproxy: page allocation failure. order:4, mode:0x20
When the slab code creates a new slab it decides up-front on a nice underlying allocation size which will pack a good number of the requested objects. So for the size-2048 slab it is currently using a 2-order (16k) allocation.
Here, you're getting 3- and even 4-order allocation attempts. Presumably because loopback uses a 16k MTU and slab has sized that up to use 64k allocations.
It's all crazy - these allocations are sure to fail all over the place. Manfred is working on fixing it up.
- 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/
| |