From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [Bugme-new] [Bug 13561] New: swapper: page allocation failure. order:0, mode:0x20 Date: Wed, 17 Jun 2009 12:16:10 -0700 Message-ID: <20090617121610.d4f0ea9d.akpm@linux-foundation.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: bugzilla-daemon@bugzilla.kernel.org, bugme-daemon@bugzilla.kernel.org, netdev@vger.kernel.org, "David S. Miller" To: nkukard@lbsd.net Return-path: Received: from smtp1.linux-foundation.org ([140.211.169.13]:54729 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752469AbZFQTQN (ORCPT ); Wed, 17 Jun 2009 15:16:13 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). 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. 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?