From: Lee Schermerhorn <lee.schermerhorn@hp.com>
To: linux-mm@vger.kernel.org
Cc: linux-numa@vger.kernel.org, eric.whitney@hp.com,
Andrew Morton <akpm@linux-foundation.org>,
Miao Xie <miaox@cn.fujitsu.com>
Subject: [PATCH 2/2] mmotm: cpusetmm-update-tasks-mems_allowed-in-time-cleanup
Date: Tue, 28 Apr 2009 14:14:31 -0400 [thread overview]
Message-ID: <20090428181431.25190.93034.sendpatchset@localhost.localdomain> (raw)
In-Reply-To: <20090428181425.25190.49303.sendpatchset@localhost.localdomain>
PATCH 2/2 cpusetmm-update-tasks-mems_allowed-in-time-cleanup
Against: 2.6.30-rc3-mmotm-090424-1814
I don't think the function name 'mpol_new_mempolicy' is
descriptive enough to differentiate it from mpol_new().
This function applies cpuset set context, usually constraining
nodes to those allowed by the cpuset. However, when the
'RELATIVE_NODES flag is set, it also translates the nodes.
So I settled on 'mpol_set_nodemask()', because the comment block
for mpol_new() mentions that we need to call this function to
"set nodes".
Some additional minor line length, whitespace and typo cleanup.
Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
mm/mempolicy.c | 28 ++++++++++++++++------------
1 file changed, 16 insertions(+), 12 deletions(-)
Index: linux-2.6.30-rc3-mmotm-090424-1814/mm/mempolicy.c
===================================================================
--- linux-2.6.30-rc3-mmotm-090424-1814.orig/mm/mempolicy.c 2009-04-28 13:32:32.000000000 -0400
+++ linux-2.6.30-rc3-mmotm-090424-1814/mm/mempolicy.c 2009-04-28 13:35:33.000000000 -0400
@@ -181,15 +181,17 @@ static int mpol_new_bind(struct mempolic
pol->v.nodes = *nodes;
return 0;
}
+
/*
- * This function is called after mpol_new(). mpol_new() has already validated
- * the nodes parameter with respect to the policy mode and flags. But, we
- * need to handle an empty nodemaks with MPOL_PREFERRED here.
+ * mpol_set_nodemask is called after mpol_new() to set up the nodemask, if
+ * any, for the new policy. mpol_new() has already validated the nodes
+ * parameter with respect to the policy mode and flags. But, we need to
+ * handle an empty nodemask with MPOL_PREFERRED here.
*
- * We use task's alloc_lock to protect task's mems_allowed and mempolicy.
- * so this function should be called with task's alloc_lock held.
+ * Must be called holding task's alloc_lock to protect task's mems_allowed
+ * and mempolicy. May also be called holding the mmap_semaphore for write.
*/
-static int mpol_new_mempolicy(struct mempolicy *pol, const nodemask_t *nodes)
+static int mpol_set_nodemask(struct mempolicy *pol, const nodemask_t *nodes)
{
nodemask_t cpuset_context_nmask;
int ret;
@@ -220,8 +222,10 @@ static int mpol_new_mempolicy(struct mem
return ret;
}
-/* This function just creates a new policy, does some check and simple
- * initializtion. You must invoke mpol_new_mempolicy to set nodes */
+/*
+ * This function just creates a new policy, does some check and simple
+ * initialization. You must invoke mpol_set_nodemask() to set nodes.
+ */
static struct mempolicy *mpol_new(unsigned short mode, unsigned short flags,
nodemask_t *nodes)
{
@@ -631,7 +635,7 @@ static long do_set_mempolicy(unsigned sh
if (mm)
down_write(&mm->mmap_sem);
task_lock(current);
- ret = mpol_new_mempolicy(new, nodes);
+ ret = mpol_set_nodemask(new, nodes);
if (ret) {
task_unlock(current);
if (mm)
@@ -1012,7 +1016,7 @@ static long do_mbind(unsigned long start
}
down_write(&mm->mmap_sem);
task_lock(current);
- err = mpol_new_mempolicy(new, nmask);
+ err = mpol_set_nodemask(new, nmask);
task_unlock(current);
if (err) {
up_write(&mm->mmap_sem);
@@ -1907,7 +1911,7 @@ void mpol_shared_policy_init(struct shar
}
task_lock(current);
- ret = mpol_new_mempolicy(new, &mpol->w.user_nodemask);
+ ret = mpol_set_nodemask(new, &mpol->w.user_nodemask);
task_unlock(current);
mpol_put(mpol); /* drop our ref on sb mpol */
if (ret) {
@@ -2138,7 +2142,7 @@ int mpol_parse_str(char *str, struct mem
int ret;
task_lock(current);
- ret = mpol_new_mempolicy(new, &nodes);
+ ret = mpol_set_nodemask(new, &nodes);
task_unlock(current);
if (ret)
err = 1;
next prev parent reply other threads:[~2009-04-28 18:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-28 18:14 [PATCH 1/2] mmotm: cpusetmm-update-tasks-mems_allowed-in-time-fix Lee Schermerhorn
2009-04-28 18:14 ` Lee Schermerhorn [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-04-28 18:02 Lee Schermerhorn
2009-04-28 18:02 ` [PATCH 2/2] mmotm: cpusetmm-update-tasks-mems_allowed-in-time-cleanup Lee Schermerhorn
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=20090428181431.25190.93034.sendpatchset@localhost.localdomain \
--to=lee.schermerhorn@hp.com \
--cc=akpm@linux-foundation.org \
--cc=eric.whitney@hp.com \
--cc=linux-mm@vger.kernel.org \
--cc=linux-numa@vger.kernel.org \
--cc=miaox@cn.fujitsu.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).