linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, ak@suse.de, mtk-manpages@gmx.net,
	clameter@sgi.com, solo@google.com,
	Lee Schermerhorn <lee.schermerhorn@hp.com>,
	eric.whitney@hp.com
Subject: [PATCH/RFC 3/5] Mem Policy:  MPOL_PREFERRED fixups for "local allocation"
Date: Thu, 30 Aug 2007 14:51:14 -0400	[thread overview]
Message-ID: <20070830185114.22619.61260.sendpatchset@localhost> (raw)
In-Reply-To: <20070830185053.22619.96398.sendpatchset@localhost>

PATCH/RFC 03/05 - MPOL_PREFERRED cleanups for "local allocation" - V4

Against: 2.6.23-rc3-mm1

V3 -> V4:
+  updated Documentation/vm/numa_memory_policy.txt to better explain
   [I think] the "local allocation" feature of MPOL_PREFERRED.

V2 -> V3:
+  renamed get_nodemask() to get_policy_nodemask() to more closely
   match what it's doing.

V1 -> V2:
+  renamed get_zonemask() to get_nodemask().  Mel Gorman suggested this
   was a valid "cleanup".

Here are a couple of "cleanups" for MPOL_PREFERRED behavior
when v.preferred_node < 0 -- i.e., "local allocation":

1)  [do_]get_mempolicy() calls the now renamed get_policy_nodemask()
    to fetch the nodemask associated with a policy.  Currently,
    get_policy_nodemask() returns the set of nodes with memory, when
    the policy 'mode' is 'PREFERRED, and the preferred_node is < 0.
    Return the set of allowed nodes instead.  This will already have
    been masked to include only nodes with memory.

2)  When a task is moved into a [new] cpuset, mpol_rebind_policy() is
    called to adjust any task and vma policy nodes to be valid in the
    new cpuset.  However, when the policy is MPOL_PREFERRED, and the
    preferred_node is <0, no rebind is necessary.  The "local allocation"
    indication is valid in any cpuset.  Existing code will "do the right
    thing" because node_remap() will just return the argument node when
    it is outside of the valid range of node ids.  However, I think it is
    clearer and cleaner to skip the remap explicitly in this case.

3)  mpol_to_str() produces a printable, "human readable" string from a
    struct mempolicy.  For MPOL_PREFERRED with preferred_node <0,  show
    the entire set of valid nodes.  Although, technically, MPOL_PREFERRED
    takes only a single node, preferred_node <0 is a local allocation policy,
    with the preferred node determined by the context where the task
    is executing.  All of the allowed nodes are possible, as the task
    migrates amoung the nodes in the cpuset.  Without this change, I believe
    that node_set() [via set_bit()] will set bit 31, resulting in a misleading
    display.

Signed-off-by:  Lee Schermerhorn <lee.schermerhorn@hp.com>

 mm/mempolicy.c |   41 ++++++++++++++++++++++++++++++-----------
 1 file changed, 30 insertions(+), 11 deletions(-)

Index: Linux/mm/mempolicy.c
===================================================================
--- Linux.orig/mm/mempolicy.c	2007-08-30 13:20:13.000000000 -0400
+++ Linux/mm/mempolicy.c	2007-08-30 13:36:04.000000000 -0400
@@ -486,8 +486,10 @@ static long do_set_mempolicy(int mode, n
 	return 0;
 }
 
-/* Fill a zone bitmap for a policy */
-static void get_zonemask(struct mempolicy *p, nodemask_t *nodes)
+/*
+ * Return a node bitmap for a policy
+ */
+static void get_policy_nodemask(struct mempolicy *p, nodemask_t *nodes)
 {
 	int i;
 
@@ -502,9 +504,11 @@ static void get_zonemask(struct mempolic
 		*nodes = p->v.nodes;
 		break;
 	case MPOL_PREFERRED:
-		/* or use current node instead of memory_map? */
+		/*
+		 * for "local policy", return allowed memories
+		 */
 		if (p->v.preferred_node < 0)
-			*nodes = node_states[N_HIGH_MEMORY];
+			*nodes = cpuset_current_mems_allowed;
 		else
 			node_set(p->v.preferred_node, *nodes);
 		break;
@@ -578,7 +582,7 @@ static long do_get_mempolicy(int *policy
 
 	err = 0;
 	if (nmask)
-		get_zonemask(pol, nmask);
+		get_policy_nodemask(pol, nmask);
 
  out:
 	if (vma)
@@ -1715,6 +1719,7 @@ static void mpol_rebind_policy(struct me
 {
 	nodemask_t *mpolmask;
 	nodemask_t tmp;
+	int nid;
 
 	if (!pol)
 		return;
@@ -1731,9 +1736,15 @@ static void mpol_rebind_policy(struct me
 						*mpolmask, *newmask);
 		break;
 	case MPOL_PREFERRED:
-		pol->v.preferred_node = node_remap(pol->v.preferred_node,
+		/*
+		 * no need to remap "local policy"
+		 */
+		nid = pol->v.preferred_node;
+		if (nid >= 0) {
+			pol->v.preferred_node = node_remap(nid,
 						*mpolmask, *newmask);
-		*mpolmask = *newmask;
+			*mpolmask = *newmask;
+		}
 		break;
 	case MPOL_BIND: {
 		nodemask_t nodes;
@@ -1808,7 +1819,7 @@ static const char * const policy_types[]
 static inline int mpol_to_str(char *buffer, int maxlen, struct mempolicy *pol)
 {
 	char *p = buffer;
-	int l;
+	int nid, l;
 	nodemask_t nodes;
 	int mode = pol ? pol->policy : MPOL_DEFAULT;
 
@@ -1818,12 +1829,20 @@ static inline int mpol_to_str(char *buff
 		break;
 
 	case MPOL_PREFERRED:
-		nodes_clear(nodes);
-		node_set(pol->v.preferred_node, nodes);
+		nid = pol->v.preferred_node;
+		/*
+		 * local interleave, show all valid nodes
+		 */
+		if (nid < 0)
+			nodes = cpuset_current_mems_allowed;
+		else {
+			nodes_clear(nodes);
+			node_set(nid, nodes);
+		}
 		break;
 
 	case MPOL_BIND:
-		get_zonemask(pol, &nodes);
+		get_policy_nodemask(pol, &nodes);
 		break;
 
 	case MPOL_INTERLEAVE:

--
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>

  parent reply	other threads:[~2007-08-30 18:51 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-30 18:50 [PATCH/RFC 0/5] Memory Policy Cleanups and Enhancements Lee Schermerhorn
2007-08-30 18:51 ` [PATCH/RFC 1/5] Mem Policy: fix reference counting Lee Schermerhorn
2007-09-11 18:48   ` Mel Gorman
2007-09-11 18:12     ` Lee Schermerhorn
2007-09-13  9:45       ` Mel Gorman
2007-08-30 18:51 ` [PATCH/RFC 2/5] Mem Policy: Use MPOL_PREFERRED for system-wide default policy Lee Schermerhorn
2007-09-11 18:54   ` Mel Gorman
2007-09-11 18:22     ` Lee Schermerhorn
2007-09-13  9:48       ` Mel Gorman
2007-08-30 18:51 ` Lee Schermerhorn [this message]
2007-09-11 18:58   ` [PATCH/RFC 3/5] Mem Policy: MPOL_PREFERRED fixups for "local allocation" Mel Gorman
2007-09-11 18:34     ` Lee Schermerhorn
2007-09-12 22:10       ` Christoph Lameter
2007-09-13 13:51         ` Lee Schermerhorn
2007-09-13 18:18           ` Christoph Lameter
2007-09-13  9:55       ` Mel Gorman
2007-09-12 22:06   ` Christoph Lameter
2007-09-13 13:35     ` Lee Schermerhorn
2007-09-13 18:21       ` Christoph Lameter
2007-08-30 18:51 ` [PATCH/RFC 4/5] Mem Policy: cpuset-independent interleave policy Lee Schermerhorn
2007-09-12 21:20   ` Ethan Solomita
2007-09-12 22:14     ` Christoph Lameter
2007-09-13 13:26     ` Lee Schermerhorn
2007-09-13 17:17       ` Ethan Solomita
2007-09-12 21:59   ` Ethan Solomita
2007-09-13 13:32     ` Lee Schermerhorn
2007-09-13 17:19       ` Ethan Solomita
2007-09-13 18:20       ` Christoph Lameter
2007-10-09  6:15       ` Ethan Solomita
2007-10-09 13:39         ` Lee Schermerhorn
2007-10-09 18:49         ` Christoph Lameter
2007-10-09 19:02           ` Lee Schermerhorn
2007-08-30 18:51 ` [PATCH/RFC 5/5] Mem Policy: add MPOL_F_MEMS_ALLOWED get_mempolicy() flag Lee Schermerhorn
2007-09-11 19:07   ` Mel Gorman
2007-09-11 18:42     ` Lee Schermerhorn
2007-09-12 22:14   ` Christoph Lameter
2007-09-14 20:24   ` [PATCH] " Lee Schermerhorn
2007-09-14 20:27     ` Christoph Lameter
2007-09-11 16:20 ` [PATCH/RFC 0/5] Memory Policy Cleanups and Enhancements Lee Schermerhorn
2007-09-11 19:12   ` Mel Gorman
2007-09-11 18:45     ` Lee Schermerhorn
2007-09-12 22:17   ` Christoph Lameter
2007-09-13 13:57     ` Lee Schermerhorn
2007-09-13 15:31       ` Mel Gorman
2007-09-13 15:01         ` Lee Schermerhorn
2007-09-13 18:55           ` Mel Gorman
2007-09-13 18:19       ` Christoph Lameter
2007-09-13 18:23         ` Mel Gorman
2007-09-13 18:26           ` Christoph Lameter
2007-09-13 21:17             ` Andrew Morton
2007-09-14  2:20               ` Christoph Lameter
2007-09-14  8:53               ` Mel Gorman
2007-09-14 15:06                 ` Lee Schermerhorn
2007-09-14 17:46                   ` Mel Gorman
2007-09-14 18:41                     ` Christoph Lameter
2007-09-16 18:02                       ` Mel Gorman
2007-09-17 18:12                         ` Christoph Lameter
2007-09-17 18:19                           ` Christoph Lameter
2007-09-17 20:14                             ` Mel Gorman
2007-09-17 19:16                               ` Christoph Lameter
2007-09-17 20:03                           ` Mel Gorman
2007-09-14 20:15                 ` Lee Schermerhorn
2007-09-16 18:05                   ` Mel Gorman
2007-09-16 19:34                     ` Andrew Morton
2007-09-16 21:22                       ` Mel Gorman
2007-09-17 13:29                     ` Lee Schermerhorn
2007-09-17 18:14                     ` Christoph Lameter
2007-09-13 15:49     ` Lee Schermerhorn
2007-09-13 18:22       ` Christoph Lameter
2007-09-17 19:00 ` [PATCH] Fix NUMA Memory Policy Reference Counting Lee Schermerhorn
2007-09-17 19:14   ` Christoph Lameter
2007-09-17 19:38     ` Lee Schermerhorn
2007-09-17 19:43       ` Christoph Lameter
2007-09-19 22:03         ` Lee Schermerhorn
2007-09-19 22:23           ` Christoph Lameter
2007-09-18 10:36   ` Mel Gorman

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=20070830185114.22619.61260.sendpatchset@localhost \
    --to=lee.schermerhorn@hp.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=eric.whitney@hp.com \
    --cc=linux-mm@kvack.org \
    --cc=mtk-manpages@gmx.net \
    --cc=solo@google.com \
    /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