public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dinakar Guniguntala <dino@in.ibm.com>
To: Paul Jackson <pj@sgi.com>
Cc: nickpiggin@yahoo.com.au, akpm@osdl.org, mbligh@google.com,
	menage@google.com, Simon.Derr@bull.net,
	linux-kernel@vger.kernel.org, rohitseth@google.com, holt@sgi.com,
	dipankar@in.ibm.com, suresh.b.siddha@intel.com
Subject: [RFC] cpuset:  Remove sched domain hooks from cpusets
Date: Tue, 31 Oct 2006 02:56:15 +0530	[thread overview]
Message-ID: <20061030212615.GA10567@in.ibm.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

Hi,

Remove the cpuset hooks that defined sched domains depending on the
setting of the 'cpu_exclusive' flag.

This patch is similar to what Paul Jackson had sent earlier, except that
since I am also attaching the alternative implementation in my next mail,
I didnt see the need to remove the API from sched.c

The existing cpuset code that partitioned sched domains at the
back of a exclusive cpuset has one major problem. Administrators
will find that tasks assigned to top level cpusets, that contain
child cpusets that are exclusive, can no longer be rebalanced across
the entire cpus_allowed mask. It was felt that instead of overloading
the cpu_exclusive flag to also create sched domains, it would be
better to have a separate flag that denotes a sched domain. That
way the admins have the flexibility to create exclusive cpusets
that do not necessarily define sched domains.

Signed-off-by: Dinakar Guniguntala <dino@in.ibm.com>


[-- Attachment #2: pj-rem.patch --]
[-- Type: text/plain, Size: 4076 bytes --]

Index: latest/kernel/cpuset.c
===================================================================
--- latest.orig/kernel/cpuset.c	2006-10-29 16:46:07.000000000 +0530
+++ latest/kernel/cpuset.c	2006-10-29 16:46:30.000000000 +0530
@@ -754,68 +754,13 @@
 }
 
 /*
- * For a given cpuset cur, partition the system as follows
- * a. All cpus in the parent cpuset's cpus_allowed that are not part of any
- *    exclusive child cpusets
- * b. All cpus in the current cpuset's cpus_allowed that are not part of any
- *    exclusive child cpusets
- * Build these two partitions by calling partition_sched_domains
- *
- * Call with manage_mutex held.  May nest a call to the
- * lock_cpu_hotplug()/unlock_cpu_hotplug() pair.
- * Must not be called holding callback_mutex, because we must
- * not call lock_cpu_hotplug() while holding callback_mutex.
- */
-
-static void update_cpu_domains(struct cpuset *cur)
-{
-	struct cpuset *c, *par = cur->parent;
-	cpumask_t pspan, cspan;
-
-	if (par == NULL || cpus_empty(cur->cpus_allowed))
-		return;
-
-	/*
-	 * Get all cpus from parent's cpus_allowed not part of exclusive
-	 * children
-	 */
-	pspan = par->cpus_allowed;
-	list_for_each_entry(c, &par->children, sibling) {
-		if (is_cpu_exclusive(c))
-			cpus_andnot(pspan, pspan, c->cpus_allowed);
-	}
-	if (!is_cpu_exclusive(cur)) {
-		cpus_or(pspan, pspan, cur->cpus_allowed);
-		if (cpus_equal(pspan, cur->cpus_allowed))
-			return;
-		cspan = CPU_MASK_NONE;
-	} else {
-		if (cpus_empty(pspan))
-			return;
-		cspan = cur->cpus_allowed;
-		/*
-		 * Get all cpus from current cpuset's cpus_allowed not part
-		 * of exclusive children
-		 */
-		list_for_each_entry(c, &cur->children, sibling) {
-			if (is_cpu_exclusive(c))
-				cpus_andnot(cspan, cspan, c->cpus_allowed);
-		}
-	}
-
-	lock_cpu_hotplug();
-	partition_sched_domains(&pspan, &cspan);
-	unlock_cpu_hotplug();
-}
-
-/*
  * Call with manage_mutex held.  May take callback_mutex during call.
  */
 
 static int update_cpumask(struct cpuset *cs, char *buf)
 {
 	struct cpuset trialcs;
-	int retval, cpus_unchanged;
+	int retval;
 
 	/* top_cpuset.cpus_allowed tracks cpu_online_map; it's read-only */
 	if (cs == &top_cpuset)
@@ -831,12 +776,9 @@
 	retval = validate_change(cs, &trialcs);
 	if (retval < 0)
 		return retval;
-	cpus_unchanged = cpus_equal(cs->cpus_allowed, trialcs.cpus_allowed);
 	mutex_lock(&callback_mutex);
 	cs->cpus_allowed = trialcs.cpus_allowed;
 	mutex_unlock(&callback_mutex);
-	if (is_cpu_exclusive(cs) && !cpus_unchanged)
-		update_cpu_domains(cs);
 	return 0;
 }
 
@@ -1046,7 +988,7 @@
 {
 	int turning_on;
 	struct cpuset trialcs;
-	int err, cpu_exclusive_changed;
+	int err;
 
 	turning_on = (simple_strtoul(buf, NULL, 10) != 0);
 
@@ -1059,14 +1001,10 @@
 	err = validate_change(cs, &trialcs);
 	if (err < 0)
 		return err;
-	cpu_exclusive_changed =
-		(is_cpu_exclusive(cs) != is_cpu_exclusive(&trialcs));
 	mutex_lock(&callback_mutex);
 	cs->flags = trialcs.flags;
 	mutex_unlock(&callback_mutex);
 
-	if (cpu_exclusive_changed)
-                update_cpu_domains(cs);
 	return 0;
 }
 
@@ -1930,17 +1868,6 @@
 	return cpuset_create(c_parent, dentry->d_name.name, mode | S_IFDIR);
 }
 
-/*
- * Locking note on the strange update_flag() call below:
- *
- * If the cpuset being removed is marked cpu_exclusive, then simulate
- * turning cpu_exclusive off, which will call update_cpu_domains().
- * The lock_cpu_hotplug() call in update_cpu_domains() must not be
- * made while holding callback_mutex.  Elsewhere the kernel nests
- * callback_mutex inside lock_cpu_hotplug() calls.  So the reverse
- * nesting would risk an ABBA deadlock.
- */
-
 static int cpuset_rmdir(struct inode *unused_dir, struct dentry *dentry)
 {
 	struct cpuset *cs = dentry->d_fsdata;
@@ -1960,13 +1887,6 @@
 		mutex_unlock(&manage_mutex);
 		return -EBUSY;
 	}
-	if (is_cpu_exclusive(cs)) {
-		int retval = update_flag(CS_CPU_EXCLUSIVE, cs, "0");
-		if (retval < 0) {
-			mutex_unlock(&manage_mutex);
-			return retval;
-		}
-	}
 	parent = cs->parent;
 	mutex_lock(&callback_mutex);
 	set_bit(CS_REMOVED, &cs->flags);

             reply	other threads:[~2006-10-30 21:26 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-30 21:26 Dinakar Guniguntala [this message]
2006-10-30 21:29 ` [RFC] cpuset: Explicit dynamic sched domain cpuset flag Dinakar Guniguntala
2006-10-31 14:43   ` Paul Jackson
2006-10-31 23:58     ` Paul Jackson
2006-11-08 10:38     ` Paul Jackson
2006-11-08 18:23       ` Dinakar Guniguntala
2006-11-08 21:22         ` Paul Jackson
  -- strict thread matches above, loose matches on Subject: below --
2006-10-19  9:23 [RFC] cpuset: remove sched domain hooks from cpusets Paul Jackson
2006-10-19 10:24 ` Nick Piggin
2006-10-19 19:03   ` Paul Jackson
2006-10-19 19:21     ` Nick Piggin
2006-10-19 19:50       ` Martin Bligh
2006-10-20  0:14         ` Paul Jackson
2006-10-20 16:03         ` Nick Piggin
2006-10-20 17:29           ` Siddha, Suresh B
2006-10-20 19:19             ` Paul Jackson
2006-10-20 19:00           ` Paul Jackson
2006-10-20 20:30             ` Dinakar Guniguntala
2006-10-20 21:41               ` Paul Jackson
2006-10-20 22:35                 ` Dinakar Guniguntala
2006-10-20 23:14                   ` Siddha, Suresh B
2006-10-21  5:37                     ` Paul Jackson
2006-10-23  4:31                       ` Siddha, Suresh B
2006-10-23  5:59                         ` Paul Jackson
2006-10-21 23:05                     ` Paul Jackson
2006-10-22 12:02                   ` Paul Jackson
2006-10-23  3:09                     ` Paul Jackson
2006-10-20 21:46               ` Paul Jackson
2006-10-21 18:23         ` Paul Menage
2006-10-21 20:55           ` Paul Jackson
2006-10-21 20:59             ` Paul Menage
2006-10-22 10:51         ` Paul Jackson
2006-10-23  5:26           ` Siddha, Suresh B
2006-10-23  5:54             ` Paul Jackson
2006-10-23  5:43               ` Siddha, Suresh B
2006-10-23  6:02               ` Nick Piggin
2006-10-23  6:16                 ` Paul Jackson
2006-10-23 16:03                 ` Christoph Lameter
2006-11-09 10:59                   ` Paul Jackson
2006-10-23 16:01               ` 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=20061030212615.GA10567@in.ibm.com \
    --to=dino@in.ibm.com \
    --cc=Simon.Derr@bull.net \
    --cc=akpm@osdl.org \
    --cc=dipankar@in.ibm.com \
    --cc=holt@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@google.com \
    --cc=menage@google.com \
    --cc=nickpiggin@yahoo.com.au \
    --cc=pj@sgi.com \
    --cc=rohitseth@google.com \
    --cc=suresh.b.siddha@intel.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