From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Andrew Morton <akpm@linux-foundation.org>,
cl@linux.com, mingo@elte.hu, mel@csn.ul.ie,
linux-kernel@vger.kernel.org, riel@redhat.com,
rientjes@google.com, xemul@openvz.org
Subject: Re: [RFC/PATCH v2] mm: Introduce GFP_PANIC for non-failing allocations
Date: Fri, 8 May 2009 17:37:04 +0400 [thread overview]
Message-ID: <20090508133704.GE6132@lenovo> (raw)
In-Reply-To: <1241787448.28600.26.camel@penberg-laptop>
[Pekka Enberg - Fri, May 08, 2009 at 03:57:28PM +0300]
| From: Cyrill Gorcunov <gorcunov@openvz.org>
|
| This patch introduces a GFP_PANIC flag that can be used as an annotation
| that a call to kmalloc() or alloc_pages() is expected to never fail.
| This is useful in early boot code, for example.
|
| To save one GFP flag bit, use a combination of __GFP_NOFAIL,
| __GFP_NOREPEAT, and __GFP_NOMEMALLOC to make sure we always end up in
| the "nopage" path of the page allocator if an allocation fails.
|
| Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
| Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
| ---
| Yes, this is totally untested and needs to be rebased on top of -mm.
|
| include/linux/gfp.h | 1 +
| mm/page_alloc.c | 3 +++
| 2 files changed, 4 insertions(+), 0 deletions(-)
|
| diff --git a/include/linux/gfp.h b/include/linux/gfp.h
| index 0bbc15f..c7c8a63 100644
| --- a/include/linux/gfp.h
| +++ b/include/linux/gfp.h
| @@ -70,6 +70,7 @@ struct vm_area_struct;
| #define GFP_HIGHUSER_MOVABLE (__GFP_WAIT | __GFP_IO | __GFP_FS | \
| __GFP_HARDWALL | __GFP_HIGHMEM | \
| __GFP_MOVABLE)
| +#define GFP_PANIC (__GFP_NOFAIL | __GFP_NORETRY | __GFP_NOMEMALLOC)
|
| #ifdef CONFIG_NUMA
| #define GFP_THISNODE (__GFP_THISNODE | __GFP_NOWARN | __GFP_NORETRY)
| diff --git a/mm/page_alloc.c b/mm/page_alloc.c
| index e2f2699..4b062e5 100644
| --- a/mm/page_alloc.c
| +++ b/mm/page_alloc.c
| @@ -1670,6 +1670,9 @@ nopage:
| dump_stack();
| show_mem();
| }
| + if (unlikely(gfp_mask & GFP_PANIC))
| + panic("Out of memory: %s order: %d, gfp_mask:0x%x\n",
| + p->comm, order, gfp_mask);
| got_pg:
| return page;
| }
| --
| 1.5.6.3
|
Thanks Pekka! At moment it's usefull for x86 uv_system_init (3 times)
for early boot code. Plain panic_on_null (suggested by Andrew) could
be usefull as well but would lead to additional wrapper around kmalloc
which is already inlined. Which means -- at moment we have those cases
handled by BUG_ON but having one common option would be better I guess
(ie have an ability to say page allocator that just do panic on fail).
Anyway, if there is still objections on such an approach (even having
gpf bits saved by elegant way Pekka suggested) -- I'm fine with having
those BUG_ONs instead of short and gracious GFP_PANIC :)
-- Cyrill
next prev parent reply other threads:[~2009-05-08 13:37 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-04 12:27 [PATCH -tip] mm: introduce __GFP_PANIC modifier Cyrill Gorcunov
2009-05-04 13:13 ` Ingo Molnar
2009-05-04 13:16 ` Cyrill Gorcunov
2009-05-04 13:47 ` Christoph Lameter
2009-05-04 14:12 ` Cyrill Gorcunov
2009-05-04 14:13 ` Christoph Lameter
2009-05-04 14:29 ` Cyrill Gorcunov
2009-05-04 15:20 ` Cyrill Gorcunov
2009-05-04 15:54 ` Christoph Lameter
2009-05-04 16:11 ` Cyrill Gorcunov
2009-05-04 19:11 ` Cyrill Gorcunov
2009-05-04 18:53 ` Andrew Morton
2009-05-04 19:21 ` Cyrill Gorcunov
2009-05-04 19:34 ` Andrew Morton
2009-05-04 20:09 ` Cyrill Gorcunov
2009-05-08 12:57 ` [RFC/PATCH v2] mm: Introduce GFP_PANIC for non-failing allocations Pekka Enberg
2009-05-08 13:37 ` Cyrill Gorcunov [this message]
2009-05-08 13:50 ` Pekka Enberg
2009-05-08 14:17 ` Christoph Lameter
2009-05-08 14:20 ` Christoph Lameter
2009-05-08 14:23 ` Pekka Enberg
2009-05-08 14:29 ` Christoph Lameter
2009-05-08 14:34 ` Pekka Enberg
2009-05-08 14:37 ` Rik van Riel
2009-05-08 14:39 ` Pekka Enberg
2009-05-08 14:43 ` Christoph Lameter
2009-05-04 19:23 ` [PATCH -tip] mm: introduce __GFP_PANIC modifier Mel Gorman
2009-05-04 19:35 ` Cyrill Gorcunov
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=20090508133704.GE6132@lenovo \
--to=gorcunov@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=xemul@openvz.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