LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: cpw@sgi.com (Cliff Wickman)
To: pj@sgi.com
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: [RFC] hotplug cpu move tasks in empty cpusets - possible refinements
Date: Fri, 18 Jan 2008 09:24:22 -0600 [thread overview]
Message-ID: <20080118152422.7038533B943@attica.americas.sgi.com> (raw)
Hi Paul,
> Query for Cliff:
> 1) Can we narrow the scope of callback_mutex in scan_for_empty_cpusets()?
> 2) Can we avoid rewriting the cpus, mems of cpusets except when it is
> likely that we'll be changing them?
> 3) Should not remove_tasks_in_empty_cpuset() also check for empty mems?
> -pj
I agree with all of the above refinements.
And I just tested the below patch and find no problem.
So this is an ACK from me.
-Cliff
---
kernel/cpuset.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
Index: linux-2.6/kernel/cpuset.c
===================================================================
--- linux-2.6.orig/kernel/cpuset.c
+++ linux-2.6/kernel/cpuset.c
@@ -1748,7 +1748,8 @@ static void remove_tasks_in_empty_cpuset
* has online cpus, so can't be empty).
*/
parent = cs->parent;
- while (cpus_empty(parent->cpus_allowed))
+ while (cpus_empty(parent->cpus_allowed) ||
+ nodes_empty(parent->mems_allowed))
parent = parent->parent;
move_member_tasks_to_cpuset(cs, parent);
@@ -1780,7 +1781,6 @@ static void scan_for_empty_cpusets(const
list_add_tail((struct list_head *)&root->stack_list, &queue);
- mutex_lock(&callback_mutex);
while (!list_empty(&queue)) {
cp = container_of(queue.next, struct cpuset, stack_list);
list_del(queue.next);
@@ -1789,19 +1789,24 @@ static void scan_for_empty_cpusets(const
list_add_tail(&child->stack_list, &queue);
}
cont = cp->css.cgroup;
+
+ /* Continue past cpusets with all cpus, mems online */
+ if (cpus_subset(cp->cpus_allowed, cpu_online_map) &&
+ nodes_subset(cp->mems_allowed, node_states[N_HIGH_MEMORY]))
+ continue;
+
/* Remove offline cpus and mems from this cpuset. */
+ mutex_lock(&callback_mutex);
cpus_and(cp->cpus_allowed, cp->cpus_allowed, cpu_online_map);
nodes_and(cp->mems_allowed, cp->mems_allowed,
node_states[N_HIGH_MEMORY]);
+ mutex_unlock(&callback_mutex);
+
+ /* Move tasks from the empty cpuset to a parent */
if (cpus_empty(cp->cpus_allowed) ||
- nodes_empty(cp->mems_allowed)) {
- /* Move tasks from the empty cpuset to a parent */
- mutex_unlock(&callback_mutex);
+ nodes_empty(cp->mems_allowed))
remove_tasks_in_empty_cpuset(cp);
- mutex_lock(&callback_mutex);
- }
}
- mutex_unlock(&callback_mutex);
}
/*
next reply other threads:[~2008-01-18 15:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-18 15:24 Cliff Wickman [this message]
2008-01-28 16:23 ` [RFC] hotplug cpu move tasks in empty cpusets - possible refinements Paul Jackson
-- strict thread matches above, loose matches on Subject: below --
2008-01-14 6:42 Paul Jackson
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=20080118152422.7038533B943@attica.americas.sgi.com \
--to=cpw@sgi.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.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).