All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Paul Jackson <pj@sgi.com>, akpm@linux-foundation.org
Cc: Mel Gorman <mel@csn.ul.ie>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	rientjes@google.com, nacc@us.ibm.com,
	kamezawa.hiroyu@jp.fujitsu.com, clameter@sgi.com,
	Eric Whitney <eric.whitney@hp.com>
Subject: [PATCH] 2.6.25-rc3-mm1 - Mempolicy - update stale documentation and comments
Date: Tue, 04 Mar 2008 15:20:56 -0500	[thread overview]
Message-ID: <1204662057.5338.104.camel@localhost> (raw)
In-Reply-To: <20080228230140.321581a4.pj@sgi.com>

Was Re: [PATCH 5/6] Filter based on a nodemask as well as a gfp_mask

On Thu, 2008-02-28 at 23:01 -0600, Paul Jackson wrote:
> Mel wrote:
> > A positive benefit of
> > this is that allocations using MPOL_BIND now use the local-node-ordered
> > zonelist instead of a custom node-id-ordered zonelist.
> 
> Could you update the now obsolete documentation (perhaps just delete
> the no longer correct remark):
> 
> Documentation/vm/numa_memory_policy.txt:
> 
>         MPOL_BIND:  This mode specifies that memory must come from the
>         set of nodes specified by the policy.
> 
>             The memory policy APIs do not specify an order in which the nodes
>             will be searched.  However, unlike "local allocation", the Bind
>             policy does not consider the distance between the nodes.  Rather,
>             allocations will fallback to the nodes specified by the policy in
>             order of numeric node id.  Like everything in Linux, this is subject
>             to change.
> 

How's this:

PATCH Mempolicy:  update documentation and comments

Address stale comments and numa_memory_policy.txt discussion
based on Mel Gorman's changes to page allocation zonelist handling.

Specifically:  mpol_free() and mpol_copy() no longer need to deal
with a custom zonelist for MPOL_BIND policy, and MPOL_BIND now
allocates memory from the nearest node with available memory in the
specified nodemask.

In "fixing" the mpol_free() and mpol_copy() comments in mempolicy.h,
I wanted to replace them with something, rather than just deleting
them.  So, I described the reference counting.  Not directly related
to the zonelist changes, but useful, IMO.

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

 Documentation/vm/numa_memory_policy.txt |   11 +++--------
 include/linux/mempolicy.h               |    8 +++++---
 2 files changed, 8 insertions(+), 11 deletions(-)

Index: linux-2.6.25-rc3-mm1/Documentation/vm/numa_memory_policy.txt
===================================================================
--- linux-2.6.25-rc3-mm1.orig/Documentation/vm/numa_memory_policy.txt	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.25-rc3-mm1/Documentation/vm/numa_memory_policy.txt	2008-03-04 14:44:51.000000000 -0500
@@ -182,14 +182,9 @@ Components of Memory Policies
 	    The Default mode does not use the optional set of nodes.
 
 	MPOL_BIND:  This mode specifies that memory must come from the
-	set of nodes specified by the policy.
-
-	    The memory policy APIs do not specify an order in which the nodes
-	    will be searched.  However, unlike "local allocation", the Bind
-	    policy does not consider the distance between the nodes.  Rather,
-	    allocations will fallback to the nodes specified by the policy in
-	    order of numeric node id.  Like everything in Linux, this is subject
-	    to change.
+	set of nodes specified by the policy.  Memory will be allocated from
+	the node in the set with sufficient free memory that is closest to
+	the node where the allocation takes place.
 
 	MPOL_PREFERRED:  This mode specifies that the allocation should be
 	attempted from the single node specified in the policy.  If that
Index: linux-2.6.25-rc3-mm1/include/linux/mempolicy.h
===================================================================
--- linux-2.6.25-rc3-mm1.orig/include/linux/mempolicy.h	2008-03-04 14:19:06.000000000 -0500
+++ linux-2.6.25-rc3-mm1/include/linux/mempolicy.h	2008-03-04 14:38:29.000000000 -0500
@@ -54,11 +54,13 @@ struct mm_struct;
  * mmap_sem.
  *
  * Freeing policy:
- * When policy is MPOL_BIND v.zonelist is kmalloc'ed and must be kfree'd.
- * All other policies don't have any external state. mpol_free() handles this.
+ * Mempolicy objects are reference counted.  A mempolicy will be freed when
+ * mpol_free() decrements the reference count to zero.
  *
  * Copying policy objects:
- * For MPOL_BIND the zonelist must be always duplicated. mpol_clone() does this.
+ * mpol_copy() allocates a new mempolicy and copies the specified mempolicy
+ * to the new storage.  The reference count of the new object is initialized
+ * to 1, representing the caller of mpol_copy().
  */
 struct mempolicy {
 	atomic_t refcnt;



WARNING: multiple messages have this Message-ID (diff)
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Paul Jackson <pj@sgi.com>, akpm@linux-foundation.org
Cc: Mel Gorman <mel@csn.ul.ie>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	rientjes@google.com, nacc@us.ibm.com,
	kamezawa.hiroyu@jp.fujitsu.com, clameter@sgi.com,
	Eric Whitney <eric.whitney@hp.com>
Subject: [PATCH] 2.6.25-rc3-mm1 - Mempolicy - update stale documentation and comments
Date: Tue, 04 Mar 2008 15:20:56 -0500	[thread overview]
Message-ID: <1204662057.5338.104.camel@localhost> (raw)
In-Reply-To: <20080228230140.321581a4.pj@sgi.com>

Was Re: [PATCH 5/6] Filter based on a nodemask as well as a gfp_mask

On Thu, 2008-02-28 at 23:01 -0600, Paul Jackson wrote:
> Mel wrote:
> > A positive benefit of
> > this is that allocations using MPOL_BIND now use the local-node-ordered
> > zonelist instead of a custom node-id-ordered zonelist.
> 
> Could you update the now obsolete documentation (perhaps just delete
> the no longer correct remark):
> 
> Documentation/vm/numa_memory_policy.txt:
> 
>         MPOL_BIND:  This mode specifies that memory must come from the
>         set of nodes specified by the policy.
> 
>             The memory policy APIs do not specify an order in which the nodes
>             will be searched.  However, unlike "local allocation", the Bind
>             policy does not consider the distance between the nodes.  Rather,
>             allocations will fallback to the nodes specified by the policy in
>             order of numeric node id.  Like everything in Linux, this is subject
>             to change.
> 

How's this:

PATCH Mempolicy:  update documentation and comments

Address stale comments and numa_memory_policy.txt discussion
based on Mel Gorman's changes to page allocation zonelist handling.

Specifically:  mpol_free() and mpol_copy() no longer need to deal
with a custom zonelist for MPOL_BIND policy, and MPOL_BIND now
allocates memory from the nearest node with available memory in the
specified nodemask.

In "fixing" the mpol_free() and mpol_copy() comments in mempolicy.h,
I wanted to replace them with something, rather than just deleting
them.  So, I described the reference counting.  Not directly related
to the zonelist changes, but useful, IMO.

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

 Documentation/vm/numa_memory_policy.txt |   11 +++--------
 include/linux/mempolicy.h               |    8 +++++---
 2 files changed, 8 insertions(+), 11 deletions(-)

Index: linux-2.6.25-rc3-mm1/Documentation/vm/numa_memory_policy.txt
===================================================================
--- linux-2.6.25-rc3-mm1.orig/Documentation/vm/numa_memory_policy.txt	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.25-rc3-mm1/Documentation/vm/numa_memory_policy.txt	2008-03-04 14:44:51.000000000 -0500
@@ -182,14 +182,9 @@ Components of Memory Policies
 	    The Default mode does not use the optional set of nodes.
 
 	MPOL_BIND:  This mode specifies that memory must come from the
-	set of nodes specified by the policy.
-
-	    The memory policy APIs do not specify an order in which the nodes
-	    will be searched.  However, unlike "local allocation", the Bind
-	    policy does not consider the distance between the nodes.  Rather,
-	    allocations will fallback to the nodes specified by the policy in
-	    order of numeric node id.  Like everything in Linux, this is subject
-	    to change.
+	set of nodes specified by the policy.  Memory will be allocated from
+	the node in the set with sufficient free memory that is closest to
+	the node where the allocation takes place.
 
 	MPOL_PREFERRED:  This mode specifies that the allocation should be
 	attempted from the single node specified in the policy.  If that
Index: linux-2.6.25-rc3-mm1/include/linux/mempolicy.h
===================================================================
--- linux-2.6.25-rc3-mm1.orig/include/linux/mempolicy.h	2008-03-04 14:19:06.000000000 -0500
+++ linux-2.6.25-rc3-mm1/include/linux/mempolicy.h	2008-03-04 14:38:29.000000000 -0500
@@ -54,11 +54,13 @@ struct mm_struct;
  * mmap_sem.
  *
  * Freeing policy:
- * When policy is MPOL_BIND v.zonelist is kmalloc'ed and must be kfree'd.
- * All other policies don't have any external state. mpol_free() handles this.
+ * Mempolicy objects are reference counted.  A mempolicy will be freed when
+ * mpol_free() decrements the reference count to zero.
  *
  * Copying policy objects:
- * For MPOL_BIND the zonelist must be always duplicated. mpol_clone() does this.
+ * mpol_copy() allocates a new mempolicy and copies the specified mempolicy
+ * to the new storage.  The reference count of the new object is initialized
+ * to 1, representing the caller of mpol_copy().
  */
 struct mempolicy {
 	atomic_t refcnt;


--
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:[~2008-03-04 20:21 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-09 14:32 [PATCH 0/6] Use one zonelist per node instead of multiple zonelists v9 Mel Gorman
2007-11-09 14:32 ` Mel Gorman
2007-11-09 14:32 ` [PATCH 1/6] Use zonelists instead of zones when direct reclaiming pages Mel Gorman
2007-11-09 14:32   ` Mel Gorman
2007-11-09 14:33 ` [PATCH 2/6] Introduce node_zonelist() for accessing the zonelist for a GFP mask Mel Gorman
2007-11-09 14:33   ` Mel Gorman
2007-11-09 15:31   ` Christoph Lameter
2007-11-09 15:31     ` Christoph Lameter
2007-11-09 14:33 ` [PATCH 3/6] Use two zonelist that are filtered by " Mel Gorman
2007-11-09 14:33   ` Mel Gorman
2007-11-09 14:33 ` [PATCH 4/6] Have zonelist contains structs with both a zone pointer and zone_idx Mel Gorman
2007-11-09 14:33   ` Mel Gorman
2007-11-20 15:34   ` Lee Schermerhorn
2007-11-20 15:34     ` Lee Schermerhorn
2007-11-09 14:34 ` [PATCH 5/6] Filter based on a nodemask as well as a gfp_mask Mel Gorman
2007-11-09 14:34   ` Mel Gorman
2008-02-29  5:01   ` Paul Jackson
2008-02-29  5:01     ` Paul Jackson
2008-02-29 14:49     ` Lee Schermerhorn
2008-02-29 14:49       ` Lee Schermerhorn
2008-03-04 20:20     ` Lee Schermerhorn [this message]
2008-03-04 20:20       ` [PATCH] 2.6.25-rc3-mm1 - Mempolicy - update stale documentation and comments Lee Schermerhorn
2008-03-05  0:35       ` Paul Jackson
2008-03-05  0:35         ` Paul Jackson
2008-03-07 11:53       ` Mel Gorman
2008-03-07 11:53         ` Mel Gorman
2007-11-09 14:34 ` [PATCH 6/6] Use one zonelist that is filtered by nodemask Mel Gorman
2007-11-09 14:34   ` Mel Gorman
2007-11-09 15:45   ` Christoph Lameter
2007-11-09 15:45     ` Christoph Lameter
2007-11-09 16:14     ` Mel Gorman
2007-11-09 16:14       ` Mel Gorman
2007-11-09 16:19       ` Christoph Lameter
2007-11-09 16:19         ` Christoph Lameter
2007-11-09 16:45       ` Nishanth Aravamudan
2007-11-09 16:45         ` Nishanth Aravamudan
2007-11-09 17:18         ` Lee Schermerhorn
2007-11-09 17:18           ` Lee Schermerhorn
2007-11-09 17:26           ` Christoph Lameter
2007-11-09 17:26             ` Christoph Lameter
2007-11-09 18:16             ` Nishanth Aravamudan
2007-11-09 18:16               ` Nishanth Aravamudan
2007-11-09 18:20               ` Nishanth Aravamudan
2007-11-09 18:20                 ` Nishanth Aravamudan
2007-11-09 18:22                 ` Christoph Lameter
2007-11-09 18:22                   ` Christoph Lameter
2007-11-11 14:16             ` Mel Gorman
2007-11-11 14:16               ` Mel Gorman
2007-11-12 19:07               ` Christoph Lameter
2007-11-12 19:07                 ` Christoph Lameter
2007-11-09 18:14           ` Nishanth Aravamudan
2007-11-09 18:14             ` Nishanth Aravamudan
2007-11-20 14:19     ` Mel Gorman
2007-11-20 14:19       ` Mel Gorman
2007-11-20 15:14       ` Lee Schermerhorn
2007-11-20 15:14         ` Lee Schermerhorn
2007-11-20 16:21         ` Mel Gorman
2007-11-20 16:21           ` Mel Gorman
2007-11-20 20:19           ` Christoph Lameter
2007-11-20 20:19             ` Christoph Lameter
2007-11-20 20:18       ` Christoph Lameter
2007-11-20 20:18         ` Christoph Lameter
2007-11-20 21:26         ` Mel Gorman
2007-11-20 21:26           ` Mel Gorman
2007-11-20 21:33         ` Andrew Morton
2007-11-20 21:33           ` Andrew Morton
2007-11-20 21:38           ` Christoph Lameter
2007-11-20 21:38             ` Christoph Lameter

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=1204662057.5338.104.camel@localhost \
    --to=lee.schermerhorn@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=eric.whitney@hp.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=nacc@us.ibm.com \
    --cc=pj@sgi.com \
    --cc=rientjes@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 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.