From: Mel Gorman <mel@csn.ul.ie>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
torvalds@linux-foundation.org, fengguang.wu@intel.com,
Pekka Enberg <penberg@cs.helsinki.fi>,
linux-kernel@vger.kernel.org
Subject: [PATCH] profile: Suppress warning about large allocations when profile=1 is specified
Date: Wed, 17 Jun 2009 13:19:14 +0100 [thread overview]
Message-ID: <20090617121913.GC28529@csn.ul.ie> (raw)
In-Reply-To: <20090617113534.GA21276@elte.hu>
On Wed, Jun 17, 2009 at 01:35:34PM +0200, Ingo Molnar wrote:
> and a separate warning popped up on another testbox:
>
> [ 0.000007] ------------[ cut here ]------------
> [ 0.000017] WARNING: at mm/page_alloc.c:1743 __alloc_pages_nodemask+0xfe/0x3fe()
> [ 0.000020] Hardware name: 1951A26
> [ 0.000022] Modules linked in:
> [ 0.000027] Pid: 0, comm: swapper Not tainted 2.6.30-tip #6031
> [ 0.000030] Call Trace:
> [ 0.000037] [<c102c1ce>] warn_slowpath_common+0x60/0x77
> [ 0.000042] [<c102c1f2>] warn_slowpath_null+0xd/0x10
> [ 0.000046] [<c107cca0>] __alloc_pages_nodemask+0xfe/0x3fe
> [ 0.000052] [<c10418df>] ? sched_clock_idle_wakeup_event+0x11/0x13
> [ 0.000057] [<c107cfb3>] alloc_pages_node+0x13/0x15
> [ 0.000060] [<c107cfe5>] __get_free_pages+0xe/0x1f
> [ 0.000066] [<c1099aee>] __kmalloc+0x2a/0x10e
> [ 0.000070] [<c1040271>] ? ktime_get+0x19/0x1b
> [ 0.000077] [<c142fdf7>] profile_init+0x47/0x81
> [ 0.000084] [<c16ed71a>] start_kernel+0x1b6/0x2c5
> [ 0.000089] [<c16ed06a>] __init_begin+0x6a/0x6f
> [ 0.000099] ---[ end trace 4eaa2a86a8e2da22 ]---
> [ 0.000999] Console: colour VGA+ 80x25
>
> Config attached here too.
>
Patch as follows
==== CUT HERE ====
profile: Suppress warning about large allocations when profile=1 is specified
When profile= is used, a large buffer is allocated early at boot. This can
be larger than what the page allocator can provide but the caller is able
to handle the situation. A warning is printed when too large an order is
given to the page allocator to indicate the caller might need fixing up
but the caller in this case is all right already. The warning looks
something like
[ 0.000007] ------------[ cut here ]------------
[ 0.000017] WARNING: at mm/page_alloc.c:1743 __alloc_pages_nodemask+0xfe/0x3fe()
[ 0.000020] Hardware name: 1951A26
[ 0.000022] Modules linked in:
[ 0.000027] Pid: 0, comm: swapper Not tainted 2.6.30-tip #6031
[ 0.000030] Call Trace:
[ 0.000037] [<c102c1ce>] warn_slowpath_common+0x60/0x77
[ 0.000042] [<c102c1f2>] warn_slowpath_null+0xd/0x10
[ 0.000046] [<c107cca0>] __alloc_pages_nodemask+0xfe/0x3fe
[ 0.000052] [<c10418df>] ? sched_clock_idle_wakeup_event+0x11/0x13
[ 0.000057] [<c107cfb3>] alloc_pages_node+0x13/0x15
[ 0.000060] [<c107cfe5>] __get_free_pages+0xe/0x1f
[ 0.000066] [<c1099aee>] __kmalloc+0x2a/0x10e
[ 0.000070] [<c1040271>] ? ktime_get+0x19/0x1b
[ 0.000077] [<c142fdf7>] profile_init+0x47/0x81
[ 0.000084] [<c16ed71a>] start_kernel+0x1b6/0x2c5
[ 0.000089] [<c16ed06a>] __init_begin+0x6a/0x6f
[ 0.000099] ---[ end trace 4eaa2a86a8e2da22 ]---
[ 0.000999] Console: colour VGA+ 80x25
This patch suppresses the warning for profile= when the order is too
high for the page allocator to satisfy.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
---
kernel/profile.c | 5 +++--
mm/page_alloc.c | 4 +++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/profile.c b/kernel/profile.c
index 69911b5..6a1ad37 100644
--- a/kernel/profile.c
+++ b/kernel/profile.c
@@ -117,11 +117,12 @@ int __ref profile_init(void)
cpumask_copy(prof_cpu_mask, cpu_possible_mask);
- prof_buffer = kzalloc(buffer_bytes, GFP_KERNEL);
+ prof_buffer = kzalloc(buffer_bytes, GFP_KERNEL|__GFP_NOWARN);
if (prof_buffer)
return 0;
- prof_buffer = alloc_pages_exact(buffer_bytes, GFP_KERNEL|__GFP_ZERO);
+ prof_buffer = alloc_pages_exact(buffer_bytes,
+ GFP_KERNEL|__GFP_ZERO|__GFP_NOWARN);
if (prof_buffer)
return 0;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a5f3c27..005b32d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1740,8 +1740,10 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
* be using allocators in order of preference for an area that is
* too large.
*/
- if (WARN_ON_ONCE(order >= MAX_ORDER))
+ if (order >= MAX_ORDER) {
+ WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
return NULL;
+ }
/*
* GFP_THISNODE (meaning __GFP_THISNODE, __GFP_NORETRY and
next prev parent reply other threads:[~2009-06-17 12:19 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 ` Mel Gorman [this message]
2009-06-20 10:09 ` [PATCH] profile: Suppress warning about large allocations when profile=1 is specified 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 ` WARNING: at mm/page_alloc.c:1159 get_page_from_freelist+0x325/0x655() Linus Torvalds
2009-06-17 16:52 ` 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=20090617121913.GC28529@csn.ul.ie \
--to=mel@csn.ul.ie \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
--cc=torvalds@linux-foundation.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