From: Rik van Riel <riel@redhat.com>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Christoph Lameter <cl@linux.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
mingo@elte.hu, mel@csn.ul.ie, linux-kernel@vger.kernel.org,
rientjes@google.com, xemul@openvz.org
Subject: Re: [RFC/PATCH v2] mm: Introduce GFP_PANIC for non-failing allocations
Date: Fri, 08 May 2009 10:37:02 -0400 [thread overview]
Message-ID: <4A04438E.6090304@redhat.com> (raw)
In-Reply-To: <1241793281.28600.43.camel@penberg-laptop>
Pekka Enberg wrote:
> On Fri, 2009-05-08 at 10:29 -0400, Christoph Lameter wrote:
>> On Fri, 8 May 2009, Pekka Enberg wrote:
>>
>>> On Fri, 8 May 2009, Pekka Enberg wrote:
>>>>> +#define GFP_PANIC (__GFP_NOFAIL | __GFP_NORETRY | __GFP_NOMEMALLOC)
>>> On Fri, 2009-05-08 at 10:20 -0400, Christoph Lameter wrote:
>>>> So this means not retrying the allocation a couple of times? Not delving
>>>> into reserve pools? Such behavior is good for a allocation that causes a
>>>> panic if it fails?
>>> If you do GFP_KERNEL|GFP_PANIC, we will cond_resched() and retry if we
>>> made some progress. So yes, I think the behavior is good for early-boot
>>> call-sites that can't really fail anyway.
>> Better make sure that GFP_PANIC is only used during early boot then.
>>
>> If memory is low on boot (due to node hotplug or some such thing, powerpc
>> may do evil tricks here) then the panic may trigger after the patch.
>> We would have just delved into the reserves a bit before.
>
> Nah, it's probably better to drop __GFP_NOMEMALLOC instead. Does this
> look better?
>
> Pekka
>
>>From c91c70265545f2fcc727b4a0d37162b5aa0f5ecf Mon Sep 17 00:00:00 2001
> From: Cyrill Gorcunov <gorcunov@openvz.org>
> Date: Fri, 8 May 2009 15:44:50 +0300
> Subject: [PATCH] mm: Introduce GFP_PANIC for non-failing allocations
>
> 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>
> ---
> include/linux/gfp.h | 1 +
> mm/page_alloc.c | 6 +++++-
> 2 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 0bbc15f..b34e6e5 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)
>
> #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..de7f666 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1556,7 +1556,8 @@ nofail_alloc:
> zonelist, high_zoneidx, ALLOC_NO_WATERMARKS);
> if (page)
> goto got_pg;
> - if (gfp_mask & __GFP_NOFAIL) {
> + /* GFP_PANIC sets both flags */
> + if ((gfp_mask & __GFP_NOFAIL) && !(gfp_mask & __GFP_NORETRY)) {
> congestion_wait(WRITE, HZ/50);
Do you mean ((gfp_mask & GFP_PANIC) == GFP_PANIC)) ?
> @@ -1670,6 +1671,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);
Ditto here.
--
All rights reversed.
next prev parent reply other threads:[~2009-05-08 14:39 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
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 [this message]
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=4A04438E.6090304@redhat.com \
--to=riel@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=gorcunov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
--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 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.