From: Mel Gorman <mel@csn.ul.ie>
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Paul Jackson <pj@sgi.com>,
akpm@linux-foundation.org, 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: Re: [PATCH] 2.6.25-rc3-mm1 - Mempolicy - update stale documentation and comments
Date: Fri, 7 Mar 2008 11:53:40 +0000 [thread overview]
Message-ID: <20080307115339.GD26229@csn.ul.ie> (raw)
In-Reply-To: <1204662057.5338.104.camel@localhost>
On (04/03/08 15:20), Lee Schermerhorn didst pronounce:
> 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>
>
Looks great.
Acked-by: Mel Gorman <mel@csn.ul.ie>
> 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;
>
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mel@csn.ul.ie>
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Paul Jackson <pj@sgi.com>,
akpm@linux-foundation.org, 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: Re: [PATCH] 2.6.25-rc3-mm1 - Mempolicy - update stale documentation and comments
Date: Fri, 7 Mar 2008 11:53:40 +0000 [thread overview]
Message-ID: <20080307115339.GD26229@csn.ul.ie> (raw)
In-Reply-To: <1204662057.5338.104.camel@localhost>
On (04/03/08 15:20), Lee Schermerhorn didst pronounce:
> 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>
>
Looks great.
Acked-by: Mel Gorman <mel@csn.ul.ie>
> 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;
>
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
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>
next prev parent reply other threads:[~2008-03-07 11:53 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 ` [PATCH] 2.6.25-rc3-mm1 - Mempolicy - update stale documentation and comments Lee Schermerhorn
2008-03-04 20:20 ` Lee Schermerhorn
2008-03-05 0:35 ` Paul Jackson
2008-03-05 0:35 ` Paul Jackson
2008-03-07 11:53 ` Mel Gorman [this message]
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=20080307115339.GD26229@csn.ul.ie \
--to=mel@csn.ul.ie \
--cc=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=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.