From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758312AbYDBBgZ (ORCPT ); Tue, 1 Apr 2008 21:36:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757284AbYDBBgA (ORCPT ); Tue, 1 Apr 2008 21:36:00 -0400 Received: from testure.choralone.org ([194.9.77.134]:53629 "EHLO testure.choralone.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757069AbYDBBf7 (ORCPT ); Tue, 1 Apr 2008 21:35:59 -0400 Date: Tue, 1 Apr 2008 21:35:51 -0400 From: Dave Jones To: Nick Piggin Cc: Linux Kernel Subject: Re: GFP_ATOMIC page allocation failures. Message-ID: <20080402013551.GA8361@codemonkey.org.uk> Mail-Followup-To: Dave Jones , Nick Piggin , Linux Kernel References: <20080401235609.GA6947@codemonkey.org.uk> <200804021228.16875.nickpiggin@yahoo.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200804021228.16875.nickpiggin@yahoo.com.au> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 02, 2008 at 12:28:16PM +1100, Nick Piggin wrote: > On Wednesday 02 April 2008 10:56, Dave Jones wrote: > > I found a few ways to cause pages and pages of spew to dmesg > > of the following form.. > > > > rhythmbox: page allocation failure. order:3, mode:0x4020 > > Pid: 4299, comm: rhythmbox Not tainted 2.6.25-0.172.rc7.git4.fc9.x86_64 #1 > > > > Call Trace: > > [] __alloc_pages+0x3a3/0x3c3 > > [] ? trace_hardirqs_on_thunk+0x35/0x3a > > [] alloc_pages_current+0x100/0x109 > > [] new_slab+0x4a/0x249 > > [] __slab_alloc+0x251/0x4e0 > > [] ? __netdev_alloc_skb+0x31/0x4f > > [] __kmalloc_node_track_caller+0x8a/0xe2 > > [] ? __netdev_alloc_skb+0x31/0x4f > > [] __alloc_skb+0x6f/0x135 > > [] __netdev_alloc_skb+0x31/0x4f > > [] :e1000e:e1000_alloc_rx_buffers+0xb7/0x1dc > > [] :e1000e:e1000_clean_rx_irq+0x271/0x307 > > [] :e1000e:e1000_clean+0x66/0x205 > > [] net_rx_action+0xd9/0x20e > > [] __do_softirq+0x70/0xf1 > > [] call_softirq+0x1c/0x28 > > [] do_softirq+0x39/0x8a > > [] irq_exit+0x4e/0x8f > > [] do_IRQ+0x145/0x167 > > [] ret_from_intr+0x0/0xf > > [] ? _spin_unlock_irqrestore+0x42/0x47 > > [] ? __wake_up+0x43/0x50 > > [] ? wake_futex+0x47/0x53 > > [] ? do_futex+0x697/0xc57 > > [] ? hrtick_set+0xa1/0xfc > > [] ? sys_futex+0xf5/0x113 > > [] ? syscall_trace_enter+0xb5/0xb9 > > [] ? tracesys+0xd5/0xda > > > > Given that we seem to recover from these events without negative effects > > (ie, no apps get oom-killed), is there any value to actually flooding > > syslog with this stuff ? > > It's nice to have. Perhaps it could just be hardlimited to print > say 10 times, and maybe we could have a vmstat counter to keep > count after that. As an end-user, that's still 10 times too many. What is anyone expect to do with these traces ? multi-page atomic allocations fail sometimes, we shouldn't be surprised by this. As long as the code that tries to do them is aware of this, is there a problem ? Dave -- http://www.codemonkey.org.uk