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 18:49:53 -0500 [thread overview]
Message-ID: <20060823234953.GH11309@localdomain> (raw)
In-Reply-To: <20060823221114.GF11309@localdomain>
Nathan Lynch wrote:
> Paul Jackson wrote:
> >
> > 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;
> +}
Actually the lock/unlock_cpu_hotplug aren't necessary,
cpu_add_remove_lock is already held in this context.
Update cpus_allowed in top_cpuset when cpus are hotplugged;
otherwise binding a task to a newly hotplugged cpu fails since the
toplevel cpuset has a static copy of whatever cpu_online_map was at
boot time.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
--- cpuhp-sched_setaffinity.orig/kernel/cpuset.c
+++ cpuhp-sched_setaffinity/kernel/cpuset.c
@@ -2033,6 +2033,29 @@ 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);
+ 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);
+ mutex_unlock(&manage_mutex);
+
+ return 0;
+}
+
/**
* cpuset_init_smp - initialize cpus_allowed
*
@@ -2043,6 +2066,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);
}
/**
next prev parent reply other threads:[~2006-08-23 23:50 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
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 [this message]
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=20060823234953.GH11309@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.