From: Linus Torvalds <torvalds@linux-foundation.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mel@csn.ul.ie>,
Catalin Marinas <catalin.marinas@arm.com>,
fengguang.wu@intel.com, Pekka Enberg <penberg@cs.helsinki.fi>,
linux-kernel@vger.kernel.org
Subject: Re: WARNING: at mm/page_alloc.c:1159 get_page_from_freelist+0x325/0x655()
Date: Wed, 17 Jun 2009 09:39:43 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.01.0906170931520.16802@localhost.localdomain> (raw)
In-Reply-To: <20090617113120.GA5061@elte.hu>
On Wed, 17 Jun 2009, Ingo Molnar wrote:
>
> a new warning started popping up today, in the new page allocator
> code. The allocation came from kmemleak:
We should probably print out the order.
Right now it warns about any order but 0, and I think that's likely bogus.
It's fine to allow small orders (I'd suggest 0-2), since we should always
be able to get those, and small kmalloc's generally do want more than one
page just to avoid crazy fragmentation issues.
See, for example, the whole 'slab_break_gfp_order' logic in mm/slab.c: it
very much expects to be able to use order-1 allocations for kmalloc() if
there is enough memory (where "enough" is actually just 32MB). And slub
seems to put some limit at PAGE_ALLOC_COSTLY_ORDER (3).
So apart from anything else (ie this particular case is possibly fixable
in kmemleak), I do think that we should likely allow at least order-1 and
possible order-2 allocations with __GFP_NOFAIL too.
Linus
next prev parent reply other threads:[~2009-06-17 16:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200906162232.n5GMWRZe026963@imap1.linux-foundation.org>
[not found] ` <20090616223649.719ea378.akpm@linux-foundation.org>
2009-06-17 11:18 ` [PATCH] pagemap: add page-types tool, fix build Ingo Molnar
2009-06-17 11:31 ` WARNING: at mm/page_alloc.c:1159 get_page_from_freelist+0x325/0x655() Ingo Molnar
2009-06-17 11:35 ` Ingo Molnar
2009-06-17 12:19 ` [PATCH] profile: Suppress warning about large allocations when profile=1 is specified Mel Gorman
2009-06-20 10:09 ` Heinz Diehl
2009-06-20 19:50 ` Mel Gorman
2009-06-20 21:48 ` Heinz Diehl
2009-06-22 11:31 ` Mel Gorman
2009-06-22 13:50 ` Heinz Diehl
2009-06-22 19:58 ` Mel Gorman
2009-06-22 17:00 ` Arnaldo Carvalho de Melo
2009-06-17 11:41 ` WARNING: at mm/page_alloc.c:1159 get_page_from_freelist+0x325/0x655() Mel Gorman
2009-06-17 12:11 ` Catalin Marinas
2009-06-17 12:28 ` Mel Gorman
2009-06-17 12:36 ` Catalin Marinas
2009-06-17 12:40 ` Mel Gorman
2009-06-17 12:52 ` [PATCH] kmemleak: Only use GFP_KERNEL|GFP_ATOMIC for the internal allocations Catalin Marinas
2009-06-17 13:01 ` Pekka Enberg
2009-06-17 13:23 ` Catalin Marinas
2009-06-17 13:30 ` Pekka Enberg
2009-06-17 15:36 ` [PATCH] kmemleak: Rename kmemleak_panic to kmemleak_stop Catalin Marinas
2009-06-17 15:37 ` Pekka Enberg
2009-06-17 17:14 ` Daniel Walker
2009-06-17 17:27 ` Catalin Marinas
2009-06-17 16:39 ` Linus Torvalds [this message]
2009-06-17 16:52 ` WARNING: at mm/page_alloc.c:1159 get_page_from_freelist+0x325/0x655() Ingo Molnar
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=alpine.LFD.2.01.0906170931520.16802@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
/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
Powered by JetHome