Re: page allocation failure

Previous thread: [PATCH]: change proto destroy method to return void by Brian Haley on Friday, June 13, 2008 - 6:55 pm. (2 messages)

Next thread: [PATCH] [resend] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM by Chris Peterson on Friday, June 13, 2008 - 10:48 pm. (2 messages)
From: Denys Fedoryshchenko
Date: Friday, June 13, 2008 - 7:25 pm

I am not sure it is error, but this message appearing on loaded PC routers.
(about 100-150Mbit/s passing there, and rtorrent also running, 1G of ram)

For example:
[1407075.519722] swapper: page allocation failure. order:3, mode:0x4020
[1407075.519722] Pid: 0, comm: swapper Not tainted 2.6.25.4-devel2 #1
[1407075.519722]  [<c0144c09>] __alloc_pages+0x2a9/0x2bd
[1407075.519722]  [<c015a606>] __slab_alloc+0x14a/0x45e
[1407075.519722]  [<c015b4c9>] __kmalloc_track_caller+0x72/0xb9
[1407075.519722]  [<c03020ae>] __netdev_alloc_skb+0x14/0x2d
[1407075.519722]  [<c03020ae>] __netdev_alloc_skb+0x14/0x2d
[1407075.519722]  [<c030156c>] __alloc_skb+0x4d/0xf9
[1407075.519722]  [<c03020ae>] __netdev_alloc_skb+0x14/0x2d
[1407075.519722]  [<f887f395>] bnx2_poll+0x58f/0xd0c [bnx2]
[1407075.519722]  [<c0307469>] net_rx_action+0xa4/0x1bf
[1407075.519722]  [<c01219fd>] __do_softirq+0x5d/0xc1
[1407075.519722]  [<c0105be4>] do_softirq+0x52/0x85
[1407075.519722]  [<c013ea70>] handle_edge_irq+0x0/0xff
[1407075.519722]  [<c012196e>] irq_exit+0x35/0x67
[1407075.519722]  [<c0105cb0>] do_IRQ+0x99/0xad
[1407075.519722]  [<c01040ef>] common_interrupt+0x23/0x28
[1407075.519722]  [<c01200d8>] sys_waitid+0x11/0x85
[1407075.519722]  [<c010260c>] default_idle+0x37/0x59
[1407075.519722]  [<c01025d5>] default_idle+0x0/0x59
[1407075.519722]  [<c010251f>] cpu_idle+0x6e/0x87
[1407075.519722]  =======================
[1407075.519722] Mem-info:
[1407075.519722] DMA per-cpu:
[1407075.519722] CPU    0: hi:    0, btch:   1 usd:   0
[1407075.519722] CPU    1: hi:    0, btch:   1 usd:   0
[1407075.519722] CPU    2: hi:    0, btch:   1 usd:   0
[1407075.519722] CPU    3: hi:    0, btch:   1 usd:   0
[1407075.519722] Normal per-cpu:
[1407075.519722] CPU    0: hi:  186, btch:  31 usd: 179
[1407075.519722] CPU    1: hi:  186, btch:  31 usd:  75
[1407075.519722] CPU    2: hi:  186, btch:  31 usd:  53
[1407075.519722] CPU    3: hi:  186, btch:  31 usd:  85
[1407075.519722] HighMem per-cpu:
[1407075.519722] CPU    0: hi:   ...
From: Evgeniy Polyakov
Date: Friday, June 13, 2008 - 11:58 pm

It should be harmless. It means that bnx2 does not support jumbo frames
separated into multiple pages and tries to allocate single huge area.


-- 
	Evgeniy Polyakov
--

From: Denys Fedoryshchenko
Date: Saturday, June 14, 2008 - 2:02 pm

There is no jumbo frames in this particular setup.
Probably it is getting out of memory (rtorrent using almost all for fs caching
maybe).

Yes, it seems harmless and seems even useless. I will ignore it from now on :-)
Thanks for info.



--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.

--

From: Ben Hutchings
Date: Saturday, June 14, 2008 - 2:36 pm

[...]

The "order: 3" means an allocation of 8 pages (32 KB) at once, which
should not be needed for receiving standard Ethernet frames.  Looking
at the bnx2 code I can't see any case in which it would allocate an
skb much larger than the MTU.

Network drivers usually try to refill the hardware RX ring immediately
after handling RX completions, at which point they are running in atomic
(non-blocking) context and large contiguous memory allocations are
relatively likely to fail even if the system has plenty of memory.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
--

From: Evgeniy Polyakov
Date: Saturday, June 14, 2008 - 11:04 pm

Hi.


Than it is very strange, why would it want to do order-3 allocation,
since its allocation size is calculated as follows:
rx_size = bp->dev->mtu + ETH_HLEN + bp->rx_offset + 8;
bp->rx_buf_use_size = rx_size;
/* hw alignment */
bp->rx_buf_size = bp->rx_buf_use_size + BNX2_RX_ALIGN

where rx_offset is 18 bytes and BNX2_RX_ALIGN is 16 bytes.
Network stack adds small structure at the end too, but it should not
jump out of 0-order allocation.

-- 
	Evgeniy Polyakov
--

Previous thread: [PATCH]: change proto destroy method to return void by Brian Haley on Friday, June 13, 2008 - 6:55 pm. (2 messages)

Next thread: [PATCH] [resend] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM by Chris Peterson on Friday, June 13, 2008 - 10:48 pm. (2 messages)