All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Lynch <ntl@pobox.com>
To: Paul Jackson <pj@sgi.com>
Cc: akpm@osdl.org, anton@samba.org, simon.derr@bull.net,
	nathanl@austin.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: cpusets not cpu hotplug aware
Date: Wed, 23 Aug 2006 17:11:14 -0500	[thread overview]
Message-ID: <20060823221114.GF11309@localdomain> (raw)
In-Reply-To: <20060821221437.255808fa.pj@sgi.com>

Paul Jackson wrote:
> Nathan wrote:
> > I think it would be more sensible for the default (i.e. user hasn't
> > explicitly configured any cpusets) behavior on a CONFIG_CPUSETS=y
> > kernel to match the behavior with a CONFIG_CPUSETS=n kernel. 
> 
> Basically, in this situation, that would mean that the code that
> masks a requested sched_setaffinity cpumask with the tasks
> cpuset_cpus_allowed():
> 
> 	cpus_allowed = cpuset_cpus_allowed(p);
> 	cpus_and(new_mask, new_mask, cpus_allowed);
> 
> would not be executed in the case of a kernel configured for cpusets,
> when running on a system that wasn't using cpusets.
> 
> That's quite doable, and for systems not actually using cpusets, makes
> good sense.
> 
> But it makes a bit of discontinuity in the system behaviour when
> someone starts using cpusets.  If someone makes a cpuset, then suddenly
> tasks in the top cpuset start seeing failed sched_setaffinity calls
> for any CPU that was brought online after system boot.
> 
> If there is some decent way I can get the cpus_allowed of the top
> cpuset to track the cpu_online_map, then we avoid this discontinuity
> in system behaviour.


How about this?  I've verified it fixes the issue but I'm nervous
about the locking.


--- cpuhp-sched_setaffinity.orig/kernel/cpuset.c
+++ cpuhp-sched_setaffinity/kernel/cpuset.c
@@ -2033,6 +2033,31 @@ out:
 	return err;
 }
 
+static int cpuset_handle_cpuhp(struct notifier_block *nb,
+				unsigned long phase, void *_cpu)
+{
+	unsigned long cpu = (unsigned long)_cpu;
+
+	mutex_lock(&manage_mutex);
+	lock_cpu_hotplug();
+	mutex_lock(&callback_mutex);
+
+	switch (phase) {
+	case CPU_ONLINE:
+		cpu_set(cpu, top_cpuset.cpus_allowed);
+		break;
+	case CPU_DEAD:
+		cpu_clear(cpu, top_cpuset.cpus_allowed);
+		break;
+	}
+
+	mutex_unlock(&callback_mutex);
+	unlock_cpu_hotplug();
+	mutex_unlock(&manage_mutex);
+
+	return 0;
+}
+
 /**
  * cpuset_init_smp - initialize cpus_allowed
  *
@@ -2043,6 +2068,8 @@ void __init cpuset_init_smp(void)
 {
 	top_cpuset.cpus_allowed = cpu_online_map;
 	top_cpuset.mems_allowed = node_online_map;
+
+	hotcpu_notifier(cpuset_handle_cpuhp, 0);
 }
 
 /**

  reply	other threads:[~2006-08-23 22:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-21 13:27 cpusets not cpu hotplug aware Anton Blanchard
2006-08-21 13:54 ` Simon Derr
2006-08-21 17:43 ` Paul Jackson
2006-08-21 19:21   ` Anton Blanchard
2006-08-21 20:42     ` [PATCH] cpuset code prevents binding tasks to new cpus Nathan Lynch
2006-08-21 23:04       ` Paul Jackson
2006-08-21 23:27         ` Nathan Lynch
2006-08-22  4:42           ` Paul Jackson
2006-08-22  5:07             ` Andrew Morton
2006-08-21 21:01     ` cpusets not cpu hotplug aware Paul Jackson
2006-08-22  4:51       ` Andrew Morton
2006-08-22  5:04         ` Nathan Lynch
2006-08-22  5:11           ` Andrew Morton
2006-08-22  5:14           ` Paul Jackson
2006-08-23 22:11             ` Nathan Lynch [this message]
2006-08-23 22:39               ` Paul Jackson
2006-08-23 23:39                 ` Nathan Lynch
2006-08-24  2:19                   ` Paul Jackson
2006-08-23 23:49               ` Nathan Lynch
2006-08-24  0:12                 ` Andrew Morton
2006-08-24  0:48                   ` [PATCH] cpuset code prevents binding tasks to new cpus Nathan Lynch
2006-08-24  2:54                   ` cpusets not cpu hotplug aware Paul Jackson
2006-08-22  5:06         ` Paul Jackson
2006-08-22  5:14           ` Andrew Morton
2006-08-22  5:21             ` Paul Jackson
2006-08-23 14:58             ` Anton Blanchard
2006-08-23 18:59               ` Paul Jackson
2006-08-23 19:08               ` 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=20060823221114.GF11309@localdomain \
    --to=ntl@pobox.com \
    --cc=akpm@osdl.org \
    --cc=anton@samba.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nathanl@austin.ibm.com \
    --cc=pj@sgi.com \
    --cc=simon.derr@bull.net \
    /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.