From: mel@skynet.skynet.ie (Mel Gorman)
To: Christoph Lameter <clameter@sgi.com>
Cc: Mel Gorman <mel@skynet.skynet.ie>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Nicolas.Mailhot@LaPoste.net,
"bugme-daemon@kernel-bugs.osdl.org"
<bugme-daemon@bugzilla.kernel.org>
Subject: Re: [Bug 8464] New: autoreconf: page allocation failure. order:2, mode:0x84020
Date: Thu, 10 May 2007 23:16:07 +0100 [thread overview]
Message-ID: <20070510221607.GA15084@skynet.ie> (raw)
In-Reply-To: <Pine.LNX.4.64.0705101510500.13404@schroedinger.engr.sgi.com>
On (10/05/07 15:11), Christoph Lameter didst pronounce:
> On Thu, 10 May 2007, Mel Gorman wrote:
>
> > I see the gfpmask was 0x84020. That doesn't look like __GFP_WAIT was set,
> > right? Does that mean that SLUB is trying to allocate pages atomically? If so,
> > it would explain why this situation could still occur even though high-order
> > allocations that could sleep would succeed.
>
> SLUB is following the gfp mask of the caller like all well behaved slab
> allocators do. If the caller does not set __GFP_WAIT then the page
> allocator also cannot wait.
Then SLUB should not use the higher orders for slab allocations that cannot
sleep during allocations. What could be done in the longer term is decide
how to tell kswapd to keep pages free at an order other than 0 when it is
known there are a large number of high-order long-lived allocations like this.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-05-10 22:16 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200705102128.l4ALSI2A017437@fire-2.osdl.org>
2007-05-10 21:43 ` Andrew Morton
2007-05-10 21:49 ` Christoph Lameter
2007-05-10 22:06 ` Mel Gorman
2007-05-10 22:11 ` Christoph Lameter
2007-05-10 22:16 ` Mel Gorman [this message]
2007-05-10 22:27 ` Christoph Lameter
2007-05-10 22:44 ` Mel Gorman
2007-05-10 22:49 ` Christoph Lameter
2007-05-10 23:00 ` Mel Gorman
2007-05-10 23:01 ` Christoph Lameter
2007-05-11 5:56 ` Nicolas Mailhot
2007-05-11 9:08 ` Mel Gorman
2007-05-11 11:51 ` Nicolas Mailhot
2007-05-11 17:38 ` Mel Gorman
2007-05-11 17:45 ` Nicolas Mailhot
2007-05-11 18:30 ` Nicolas Mailhot
2007-05-11 20:36 ` Mel Gorman
2007-05-12 8:11 ` Nicolas Mailhot
2007-05-12 16:42 ` Mel Gorman
2007-05-12 18:09 ` Nicolas Mailhot
2007-05-12 18:58 ` Nicolas Mailhot
2007-05-12 19:24 ` Mel Gorman
2007-05-13 8:16 ` Nicolas Mailhot
2007-05-11 17:46 ` Christoph Lameter
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=20070510221607.GA15084@skynet.ie \
--to=mel@skynet.skynet.ie \
--cc=Nicolas.Mailhot@LaPoste.net \
--cc=akpm@linux-foundation.org \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox