From: Andrew Morton <akpm@linux-foundation.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [Bugme-new] [Bug 16083] New: swapper: Page allocation failure
Date: Thu, 3 Jun 2010 13:02:35 -0700 [thread overview]
Message-ID: <20100603130235.c372b38f.akpm@linux-foundation.org> (raw)
In-Reply-To: <bug-16083-10286@https.bugzilla.kernel.org/>
On Mon, 31 May 2010 15:55:12 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=16083
>
> Summary: swapper: Page allocation failure
> Product: Memory Management
> Version: 2.5
> Kernel Version: 2.6.34
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: akpm@linux-foundation.org
> ReportedBy: sgunderson@bigfoot.com
> Regression: No
>
>
> Hi,
>
> Since upgrading from a Q9450 to 2xE5520 (and upgrading from 2.6.34-rc-something
> to 2.6.34), I've started seeing these:
>
> [605882.372418] swapper: page allocation failure. order:2, mode:0x4020
> [605882.378981] Pid: 0, comm: swapper Not tainted 2.6.34 #1
> [605882.384617] Call Trace:
> [605882.387499] <IRQ> [<ffffffff81096d5a>] __alloc_pages_nodemask+0x5b0/0x629
> [605882.395068] [<ffffffff81096de5>] __get_free_pages+0x12/0x4f
> [605882.401103] [<ffffffff810bdeb4>] __kmalloc_track_caller+0x4c/0x156
> [605882.407817] [<ffffffff81245986>] ? sock_alloc_send_pskb+0xdd/0x32d
> [605882.414556] [<ffffffff8124a515>] __alloc_skb+0x66/0x15b
I wonder if we should switch __alloc_skb() over to __GFP_NOWARN.
People keep on reporting events such as the above, and nobody's
getting any value from this.
Downsides:
- the change would tend to deprive MM developers of prompt "hey you
broke it again" notifications.
- if a system is getting enough allocation failures to impact
throughput, the operators won't *know* that it's happening, and so
they won't make the changes necessary to reduce the frequency of
memory allocation failures.
If these are likely to be a problem, perhaps networking could provide
some other form of "hey, you keep on running out of memory"
notification, if it doesn't already do so.
Thoughts?
next parent reply other threads:[~2010-06-03 20:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-16083-10286@https.bugzilla.kernel.org/>
2010-06-03 20:02 ` Andrew Morton [this message]
2010-06-03 21:13 ` [Bugme-new] [Bug 16083] New: swapper: Page allocation failure Eric Dumazet
2010-06-03 21:37 ` Eric Dumazet
2010-06-03 22:01 ` Andrew Morton
2010-06-05 10:04 ` David Miller
2010-06-03 21:39 ` Andrew Morton
2010-06-03 21:58 ` Eric Dumazet
2010-06-03 22:11 ` Andrew Morton
2010-06-05 9:59 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100603130235.c372b38f.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.