From: Mel Gorman <mel@csn.ul.ie>
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, ak@suse.de,
mtk-manpages@gmx.net, clameter@sgi.com, solo@google.com,
eric.whitney@hp.com
Subject: Re: [PATCH/RFC 3/5] Mem Policy: MPOL_PREFERRED fixups for "local allocation"
Date: Tue, 11 Sep 2007 19:58:19 +0100 [thread overview]
Message-ID: <1189537099.32731.92.camel@localhost> (raw)
In-Reply-To: <20070830185114.22619.61260.sendpatchset@localhost>
On Thu, 2007-08-30 at 14:51 -0400, Lee Schermerhorn wrote:
> 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.
>
Better name all right.
> 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;
Is this change intentional? It looks like something that belongs as part
of the the memoryless patch set.
> 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>
--
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:[~2007-09-11 18:58 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 ` [PATCH/RFC 3/5] Mem Policy: MPOL_PREFERRED fixups for "local allocation" Lee Schermerhorn
2007-09-11 18:58 ` Mel Gorman [this message]
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=1189537099.32731.92.camel@localhost \
--to=mel@csn.ul.ie \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=eric.whitney@hp.com \
--cc=lee.schermerhorn@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;
as well as URLs for NNTP newsgroup(s).