From: Paul Jackson <pj@sgi.com>
To: David Rientjes <rientjes@google.com>
Cc: akpm@linux-foundation.org, ak@suse.de, clameter@sgi.com,
Lee.Schermerhorn@hp.com, linux-kernel@vger.kernel.org
Subject: Re: [patch 2/2] cpusets: add interleave_over_allowed option
Date: Thu, 25 Oct 2007 18:13:37 -0700 [thread overview]
Message-ID: <20071025181337.b27cd309.pj@sgi.com> (raw)
In-Reply-To: <alpine.DEB.0.9999.0710251541550.11929@chino.kir.corp.google.com>
I'm probably going to be ok with this ... after a bit.
1) First concern - my primary issue:
One thing I really want to change, the name of the per-cpuset file
that controls this option. You call it "interleave_over_allowed".
Take a look at the existing per-cpuset file names:
$ grep 'name = "' kernel/cpuset.c
.name = "cpuset",
.name = "cpus",
.name = "mems",
.name = "cpu_exclusive",
.name = "mem_exclusive",
.name = "sched_load_balance",
.name = "memory_migrate",
.name = "memory_pressure_enabled",
.name = "memory_pressure",
.name = "memory_spread_page",
.name = "memory_spread_slab",
.name = "cpuset",
The name of every memory related option starts with "mem" or "memory",
and the name of every memory interleave related option starts with
"memory_spread_*".
Can we call this "memory_spread_user" instead, or something else
matching "memory_spread_*" ?
The names of things in the public API's are a big issue of mine.
2) Second concern - lessor code clarity issue:
The logic surrounding current_cpuset_interleaved_mems() seems a tad
opaque to me. It appears on the surface as if the memory policy code,
in mm/mempolicy.c, is getting a nodemask from the cpuset code by
calling this routine, as if there were an independent per-cpuset
nodemask stating over what nodes to interleave for MPOL_INTERLEAVE.
But all that is returned is either (1) an empty node mask or (2) the
current tasks allowed cpu mask. If an empty mask is returned, this
tells the MPOL_INTERLEAVE code to use the mask the user specified in
an earlier set_mempolicy MPOL_INTERLEAVE call. If a non-empty mask
is returned, then the previous user specified mask is ignored and
that non-empty mask (just all the current cpusets allowed nodes) is
used instead.
Restating this in pseudo code, from your patch, the mempolicy.c
MPOL_INTERLEAVE code to rebind memory policies after a cpuset
changes reads:
tmp = current_cpuset_interleaved_mems();
if tmp empty:
rebind over tmp (all the cpusets allowed nodes)
break;
rebind over the set_mempolicy MPOL_INTERLEAVE specified mask
break;
The above code is assymmetric, and the returning of a nodemask is
an illusion, suggesting that cpusets might have an interleaved
nodemask separate from the allowed memory nodemask.
How about instead of your current_cpuset_interleaved_mems() routine
that returns a nodemask, rather have a routine that returns a Boolean,
indicating whether this new flag is set, used as in:
if (cpuset_is_memory_spread_user())
tmp = cpuset_current_mems_allowed();
else
nodes_remap(tmp, pol->v.nodes, *mpolmask, *newmask);
pol->v.nodes = tmp;
I'll wager this saves a few bytes of kernel text space as well.
3) Maybe I haven't had enough caffiene yet third issue:
The existing kernel code for mm/mempolicy.c:mpol_rebind_policy()
looks buggy to me. The node_remap() call for the MPOL_INTERLEAVE
case seems like it should come before, not after, updating mpolmask
to the newmask. Fixing that, and consolidating the multiple lines
doing "*mpolmask = *newmask" for each case, into a single such line
at the end of the switch(){} statement, results in the following
patch. Could you confirm my suspicions and push this one too.
It should be a part of your patch set, so we don't waste Andrew's
time resolving the inevitable patch collisions we'll see otherwise.
--- 2.6.23-mm1.orig/mm/mempolicy.c 2007-10-16 18:55:34.745039423 -0700
+++ 2.6.23-mm1/mm/mempolicy.c 2007-10-25 18:06:08.474742762 -0700
@@ -1741,14 +1741,12 @@ static void mpol_rebind_policy(struct me
case MPOL_INTERLEAVE:
nodes_remap(tmp, pol->v.nodes, *mpolmask, *newmask);
pol->v.nodes = tmp;
- *mpolmask = *newmask;
current->il_next = node_remap(current->il_next,
*mpolmask, *newmask);
break;
case MPOL_PREFERRED:
pol->v.preferred_node = node_remap(pol->v.preferred_node,
*mpolmask, *newmask);
- *mpolmask = *newmask;
break;
case MPOL_BIND: {
nodemask_t nodes;
@@ -1773,13 +1771,14 @@ static void mpol_rebind_policy(struct me
kfree(pol->v.zonelist);
pol->v.zonelist = zonelist;
}
- *mpolmask = *newmask;
break;
}
default:
BUG();
break;
}
+
+ *mpolmask = *newmask;
}
/*
Thanks.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
next prev parent reply other threads:[~2007-10-26 1:13 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-25 22:54 [patch 1/2] cpusets: extract mmarray loading from update_nodemask David Rientjes
2007-10-25 22:54 ` [patch 2/2] cpusets: add interleave_over_allowed option David Rientjes
2007-10-25 23:37 ` Christoph Lameter
2007-10-25 23:56 ` David Rientjes
2007-10-26 0:28 ` Christoph Lameter
2007-10-26 1:55 ` Paul Jackson
2007-10-26 2:11 ` David Rientjes
2007-10-26 2:29 ` Paul Jackson
2007-10-26 2:45 ` David Rientjes
2007-10-26 3:14 ` Paul Jackson
2007-10-26 3:58 ` David Rientjes
2007-10-26 4:34 ` Paul Jackson
2007-10-26 15:37 ` Lee Schermerhorn
2007-10-26 17:04 ` Paul Jackson
2007-10-26 17:28 ` Lee Schermerhorn
2007-10-26 20:21 ` Michael Kerrisk
2007-10-26 20:25 ` Paul Jackson
2007-10-26 20:33 ` Michael Kerrisk
2007-10-26 15:30 ` Lee Schermerhorn
2007-10-26 18:46 ` David Rientjes
2007-10-26 19:00 ` Paul Jackson
2007-10-26 20:45 ` David Rientjes
2007-10-26 21:05 ` Christoph Lameter
2007-10-26 21:08 ` David Rientjes
2007-10-26 21:12 ` Christoph Lameter
2007-10-26 21:15 ` David Rientjes
2007-10-26 21:13 ` Lee Schermerhorn
2007-10-26 21:17 ` Christoph Lameter
2007-10-26 21:26 ` Lee Schermerhorn
2007-10-26 21:37 ` Christoph Lameter
2007-10-29 15:00 ` Lee Schermerhorn
2007-10-29 17:33 ` Paul Jackson
2007-10-29 17:46 ` Lee Schermerhorn
2007-10-29 20:35 ` Christoph Lameter
2007-10-26 21:18 ` David Rientjes
2007-10-26 21:31 ` Lee Schermerhorn
2007-10-26 21:39 ` David Rientjes
2007-10-27 1:07 ` Paul Jackson
2007-10-27 1:26 ` Christoph Lameter
2007-10-27 2:41 ` Paul Jackson
2007-10-27 2:50 ` Christoph Lameter
2007-10-27 5:16 ` Paul Jackson
2007-10-27 6:07 ` Christoph Lameter
2007-10-27 8:36 ` Paul Jackson
2007-10-27 17:47 ` Christoph Lameter
2007-10-27 20:59 ` Paul Jackson
2007-10-27 17:50 ` David Rientjes
2007-10-27 23:19 ` Paul Jackson
2007-10-28 18:19 ` David Rientjes
2007-10-28 23:46 ` Paul Jackson
2007-10-29 1:04 ` David Rientjes
2007-10-29 4:27 ` Paul Jackson
2007-10-29 4:47 ` David Rientjes
2007-10-29 5:45 ` Paul Jackson
2007-10-29 7:00 ` David Rientjes
2007-10-29 7:26 ` Paul Jackson
2007-10-30 22:53 ` David Rientjes
2007-10-30 23:17 ` Paul Jackson
2007-10-30 23:25 ` David Rientjes
2007-10-31 0:03 ` Paul Jackson
2007-10-31 0:05 ` Paul Jackson
2007-10-29 7:15 ` Paul Jackson
2007-10-30 23:12 ` David Rientjes
2007-10-30 23:44 ` Paul Jackson
2007-10-30 23:53 ` David Rientjes
2007-10-31 0:29 ` Paul Jackson
2007-10-29 16:54 ` Lee Schermerhorn
2007-10-29 19:40 ` Paul Jackson
2007-10-29 19:45 ` Paul Jackson
2007-10-29 19:57 ` Paul Jackson
2007-10-29 20:02 ` Paul Jackson
2007-10-27 17:45 ` David Rientjes
2007-10-27 21:22 ` Paul Jackson
2007-10-29 15:10 ` Lee Schermerhorn
2007-10-29 18:41 ` Paul Jackson
2007-10-29 19:01 ` Lee Schermerhorn
2007-10-30 23:17 ` David Rientjes
2007-10-31 0:03 ` Paul Jackson
2007-10-30 22:57 ` David Rientjes
2007-10-30 23:46 ` Paul Jackson
2007-10-26 20:43 ` Lee Schermerhorn
2007-10-26 15:18 ` Lee Schermerhorn
2007-10-26 17:36 ` Christoph Lameter
2007-10-26 18:45 ` David Rientjes
2007-10-26 19:02 ` Paul Jackson
2007-10-27 19:16 ` David Rientjes
2007-10-29 16:23 ` Lee Schermerhorn
2007-10-29 17:35 ` Andi Kleen
2007-10-29 19:35 ` Paul Jackson
2007-10-29 20:36 ` Christoph Lameter
2007-10-29 21:08 ` Andi Kleen
2007-10-29 22:48 ` Paul Jackson
2007-10-30 19:47 ` Paul Jackson
2007-10-30 20:20 ` Lee Schermerhorn
2007-10-30 20:26 ` Paul Jackson
2007-10-30 20:27 ` Andi Kleen
2007-10-26 1:13 ` Paul Jackson [this message]
2007-10-26 1:30 ` David Rientjes
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=20071025181337.b27cd309.pj@sgi.com \
--to=pj@sgi.com \
--cc=Lee.Schermerhorn@hp.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--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.