All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@openvz.org>
To: Andrew Morton <akpm@linux-foundation.org>,
	Christoph Lameter <cl@linux-foundation.org>,
	Mel Gorman <mel@csn.ul.ie>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	Ingo Molnar <mingo@elte.hu>, Rik van Riel <riel@redhat.com>,
	David Rientjes <rientjes@google.com>,
	Pavel Emelyanov <xemul@openvz.org>
Subject: [PATCH -tip] mm: introduce __GFP_PANIC modifier
Date: Mon, 4 May 2009 16:27:40 +0400	[thread overview]
Message-ID: <20090504122740.GH4173@lenovo> (raw)

Hi,

here is an attempt to bring in __GFP_PANIC modifier.
The patch is made on top of -tip repo. I've been
trying to apply it in top of -mm tree but it
seems -tip is a bit newer, at least it already
has __GFP_BITS_SHIFT = 22 defined.

Mel, could you take a look?

For easier review -- here is what is done:
1) __GFP_PANIC introduced
2) __alloc_pages_internal now checks for this flag
   and panic if needed.

	-- Cyrill
---
From: Cyrill Gorcunov <gorcunov@openvz.org>
Subject: [PATCH -tip] mm: introduce __GFP_PANIC modifier

Sometime we need that memory obtained via kmalloc
is always granted cause if there is not enough memory
we just can't go further.

For such a case we introduce __GFP_PANIC modificator
If memory can't be granted -- we just panic and halt.

Note 1: it trigger panic only if we reach out-of-memory
situation. MAX_ORDER and SLAB built-in constants are
not covered by intent.

Note 2: __GFP_PANIC implicitly turn off failslab
facility on such kind of calls.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
 include/linux/gfp.h |    4 +++-
 mm/failslab.c       |    3 +++
 mm/page_alloc.c     |   10 ++++++++--
 3 files changed, 14 insertions(+), 3 deletions(-)

Index: linux-2.6.git/include/linux/gfp.h
=====================================================================
--- linux-2.6.git.orig/include/linux/gfp.h
+++ linux-2.6.git/include/linux/gfp.h
@@ -58,7 +58,9 @@ struct vm_area_struct;
 #define __GFP_NOTRACK	((__force gfp_t)0)
 #endif
 
-#define __GFP_BITS_SHIFT 22	/* Room for 22 __GFP_FOO bits */
+#define __GFP_PANIC	((__force gfp_t)0x400000u) /* Panic on page alloction failure */
+
+#define __GFP_BITS_SHIFT 23	/* Room for 23 __GFP_FOO bits */
 #define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1))
 
 /* This equals 0, but use constants in case they ever change */
Index: linux-2.6.git/mm/failslab.c
=====================================================================
--- linux-2.6.git.orig/mm/failslab.c
+++ linux-2.6.git/mm/failslab.c
@@ -17,6 +17,9 @@ bool should_failslab(size_t size, gfp_t 
 	if (gfpflags & __GFP_NOFAIL)
 		return false;
 
+	if (gfpflags & __GFP_PANIC)
+		return false;
+
         if (failslab.ignore_gfp_wait && (gfpflags & __GFP_WAIT))
 		return false;
 
Index: linux-2.6.git/mm/page_alloc.c
=====================================================================
--- linux-2.6.git.orig/mm/page_alloc.c
+++ linux-2.6.git/mm/page_alloc.c
@@ -1185,6 +1185,8 @@ static int should_fail_alloc_page(gfp_t 
 		return 0;
 	if (gfp_mask & __GFP_NOFAIL)
 		return 0;
+	if (gfp_mask & __GFP_PANIC)
+		return 0;
 	if (fail_page_alloc.ignore_gfp_highmem && (gfp_mask & __GFP_HIGHMEM))
 		return 0;
 	if (fail_page_alloc.ignore_gfp_wait && (gfp_mask & __GFP_WAIT))
@@ -1506,7 +1508,7 @@ restart:
 		 * Happens if we have an empty zonelist as a result of
 		 * GFP_THISNODE being used on a memoryless node
 		 */
-		return NULL;
+		goto nopage;
 	}
 
 	page = get_page_from_freelist(gfp_mask|__GFP_HARDWALL, nodemask, order,
@@ -1685,7 +1687,11 @@ nopage:
 		dump_stack();
 		show_mem();
 	}
-	return page;
+	if (unlikely(gfp_mask & __GFP_PANIC))
+		panic("Out of memory: panic due to __GFP_PANIC."
+			" %s order:%d, gfp_mask:0x%x\n", p->comm,
+			order, gfp_mask);
+	return NULL;
 got_pg:
 	if (kmemcheck_enabled)
 		kmemcheck_pagealloc_alloc(page, order, gfp_mask);

             reply	other threads:[~2009-05-04 12:27 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-04 12:27 Cyrill Gorcunov [this message]
2009-05-04 13:13 ` [PATCH -tip] mm: introduce __GFP_PANIC modifier 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
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=20090504122740.GH4173@lenovo \
    --to=gorcunov@openvz.org \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --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 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.