linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <clameter@sgi.com>
To: akpm@osdl.org
Cc: linux-mm@kvack.org
Subject: [PATCH] GFP_THISNODE must not trigger global reclaim
Date: Wed, 29 Nov 2006 15:07:35 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0611291503320.17858@schroedinger.engr.sgi.com> (raw)

The intent of GFP_THISNODE is to make sure that an allocation occurs on a 
particular node. If this is not possible then NULL needs to be returned so 
that the caller can choose what to do next on its own (the slab allocator 
depends on that).

However, GFP_THISNODE currently triggers reclaim before returning a 
failure (GFP_THISNODE means GFP_NORETRY is set). If we have over allocated 
a node then we will currently do some reclaim before returning NULL. The 
caller may want memory from other nodes before reclaim should be 
triggered. (If the caller wants reclaim then he can directly use 
__GFP_THISNODE instead).

There is no flag to avoid reclaim in the page allocator and adding yet 
another GFP_xx flag would be difficult given that we are out of available 
flags.

So just compare and see if all bits for GFP_THISNODE (__GFP_THISNODE, 
__GFP_NORETRY and __GFP_NOWARN) are set. If so then we return NULL before 
waking up kswapd.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: linux-2.6.19-rc6-mm1/mm/page_alloc.c
===================================================================
--- linux-2.6.19-rc6-mm1.orig/mm/page_alloc.c	2006-11-29 16:10:30.257282914 -0600
+++ linux-2.6.19-rc6-mm1/mm/page_alloc.c	2006-11-29 16:10:56.697054927 -0600
@@ -1307,6 +1307,17 @@ restart:
 	if (page)
 		goto got_pg;
 
+	/*
+	 * GFP_THISNODE (meaning __GFP_THISNODE, __GFP_NORETRY and
+	 * __GFP_NOWARN set) should not cause reclaim since the subsystem
+	 * (f.e. slab) using GFP_THISNODE may choose to trigger reclaim
+	 * using a larger set of nodes after it has established that the
+	 * allowed per node queues are empty and that nodes are
+	 * over allocated.
+	 */
+	if (NUMA_BUILD && (gfp_mask & GFP_THISNODE) == GFP_THISNODE)
+		goto nopage;
+
 	for (z = zonelist->zones; *z; z++)
 		wakeup_kswapd(*z, order);
 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

                 reply	other threads:[~2006-11-29 23:07 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=Pine.LNX.4.64.0611291503320.17858@schroedinger.engr.sgi.com \
    --to=clameter@sgi.com \
    --cc=akpm@osdl.org \
    --cc=linux-mm@kvack.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