From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nigel Kukard Subject: Re: [Bugme-new] [Bug 13561] New: swapper: page allocation failure. order:0, mode:0x20 Date: Wed, 17 Jun 2009 19:29:25 +0000 Message-ID: <4A394415.30004@lbsd.net> References: <20090617121610.d4f0ea9d.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: bugzilla-daemon@bugzilla.kernel.org, bugme-daemon@bugzilla.kernel.org, netdev@vger.kernel.org, "David S. Miller" To: Andrew Morton Return-path: Received: from authsmtp-0-3.virt.iitsp.net ([66.197.161.151]:59966 "EHLO authsmtp-0-3.virt.iitsp.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751946AbZFQTiU (ORCPT ); Wed, 17 Jun 2009 15:38:20 -0400 In-Reply-To: <20090617121610.d4f0ea9d.akpm@linux-foundation.org> Sender: netdev-owner@vger.kernel.org List-ID: > > On Wed, 17 Jun 2009 18:41:24 GMT > bugzilla-daemon@bugzilla.kernel.org wrote: > > >> http://bugzilla.kernel.org/show_bug.cgi?id=13561 >> >> Summary: swapper: page allocation failure. order:0, mode:0x20 >> Product: Memory Management >> >> ... >> >> [ 1884.639134] swapper: page allocation failure. order:0, mode:0x20 >> [ 1884.639136] Pid: 0, comm: swapper Tainted: P 2.6.29.4-1.0 #1 >> [ 1884.639137] Call Trace: >> [ 1884.639139] [] __alloc_pages_internal+0x41e/0x43f >> [ 1884.639146] [] alloc_pages_current+0xb9/0xc2 >> [ 1884.639149] [] new_slab+0xcf/0x28c >> [ 1884.639151] [] __slab_alloc+0x200/0x3e2 >> [ 1884.639154] [] ? __alloc_skb+0x42/0x131 >> [ 1884.639157] [] ? _spin_lock_irqsave+0x28/0x31 >> [ 1884.639160] [] ? __alloc_skb+0x42/0x131 >> [ 1884.639162] [] kmem_cache_alloc_node+0x7c/0xc6 >> [ 1884.639165] [] ? __mod_timer+0xb3/0xc5 >> [ 1884.639168] [] __alloc_skb+0x42/0x131 >> [ 1884.639171] [] tcp_send_ack+0x2b/0x112 >> [ 1884.639173] [] __tcp_ack_snd_check+0x65/0x7d >> [ 1884.639176] [] tcp_rcv_established+0x7d7/0x926 >> [ 1884.639179] [] tcp_v4_do_rcv+0x1b1/0x35e >> [ 1884.639181] [] tcp_v4_rcv+0x4a6/0x785 >> [ 1884.639185] [] ip_local_deliver_finish+0x177/0x25a >> [ 1884.639187] [] ip_local_deliver+0x72/0x7a >> [ 1884.639190] [] ip_rcv_finish+0x32b/0x345 >> [ 1884.639192] [] ip_rcv+0x27c/0x2b9 >> [ 1884.639195] [] netif_receive_skb+0x471/0x496 >> [ 1884.639201] [] rtl8169_rx_interrupt+0x362/0x43d [r8169] >> [ 1884.639205] [] rtl8169_poll+0x3f/0x1fe [r8169] >> [ 1884.639208] [] net_rx_action+0xae/0x19c >> [ 1884.639212] [] __do_softirq+0x8a/0x139 >> [ 1884.639214] [] call_softirq+0x1c/0x30 >> [ 1884.639217] [] do_softirq+0x44/0x8f >> [ 1884.639219] [] irq_exit+0x3f/0x7e >> [ 1884.639222] [] do_IRQ+0xc3/0xe4 >> [ 1884.639224] [] ret_from_intr+0x0/0x29 >> [ 1884.639225] [] ? native_safe_halt+0x6/0x8 >> [ 1884.639230] [] ? default_idle+0x2e/0x4b >> [ 1884.639233] [] ? c1e_idle+0x109/0x110 >> [ 1884.639235] [] ? atomic_notifier_call_chain+0x13/0x15 >> [ 1884.639239] [] ? cpu_idle+0x59/0x9a >> [ 1884.639242] [] ? start_secondary+0x254/0x25b >> > > yep, that's OK. The kernel was excessively low on memory and the > network driver was unable to allocate a page for a received packet. > Even though the box had 4Gbyte RAM with nothing running but console? maybe I"m mistaking the amount of RAM for the amount of memory in a buffer used for network IO? -N > The packet will just be dropped and everything should recover. If you > get a lot of these warnings (one per minute?) then increasing the value > in /proc/sys/vm/min_free_kbytes should help. > > > Dave, we get quite a few reports of this nature, especially from e1000 > (grr). Do you think we could/should suppress the warning, by > sprinkling a few __GFP_NOWARNs in the right places? It doesn't seem > like it's being very useful? > > >