From: Nathan Lynch <ntl@pobox.com>
To: Anton Blanchard <anton@samba.org>
Cc: Paul Jackson <pj@sgi.com>,
simon.derr@bull.net, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@osdl.org>
Subject: [PATCH] cpuset code prevents binding tasks to new cpus
Date: Mon, 21 Aug 2006 15:42:51 -0500 [thread overview]
Message-ID: <20060821204251.GB9828@localdomain> (raw)
In-Reply-To: <20060821192133.GC8499@krispykreme>
Anton Blanchard wrote:
>
> Hi,
>
> > Your query confuses me, about 4 different ways ...
> >
> > 1) What does sched_setaffinity have to do with this part of cpusets?
>
> long sched_setaffinity(pid_t pid, cpumask_t new_mask)
> {
> ...
> cpus_allowed = cpuset_cpus_allowed(p);
> cpus_and(new_mask, new_mask, cpus_allowed);
> retval = set_cpus_allowed(p, new_mask);
>
> If cpuset_cpus_allowed doesnt return the current online mask and we want
> to schedule on a cpu that has been added since boot it looks like we
> will fail.
>
> > 2) What did you mean by "statically assigned"? At boot, whatever cpus
> > and memory nodes are online are copied to the top_cpuset's settings.
> > As Simon suggests, it would be up to the hotplug/hotunplug folks to
> > update these top_cpuset settings, as cpus and nodes come and go.
>
> Its up to the cpusets code to register a hotplug notifier to update the
> top_cpuset maps.
I think a notifier is overkill, the top_cpuset mask should just be a
copy of cpu_possible_map, which doesn't change after boot so we don't
have to worry about keeping it in sync. cpuset_cpus_allowed already
guarantees online cpus in the returned mask.
> > 3) I don't understand what you thought was suspicious here.
> > 4) I don't understand what you expected to see instead here.
>
> If the top level cpuset pointed to cpu_online_map instead of a boot time
> copy we wouldnt need any hotplug gunk in the cpusets code.
>
> Maybe the notifier is the right way to go, but it seems strange to
> create two copies of cpu_online_map (with the associated possibiliy of
> the two getting out of sync).
Agreed.
Here's a patch:
We have this code in sched_setaffinity:
cpus_allowed = cpuset_cpus_allowed(p);
cpus_and(new_mask, new_mask, cpus_allowed);
retval = set_cpus_allowed(p, new_mask);
In the default case (the task belongs to the default toplevel cpuset),
cpuset_cpus_allowed always returns a copy of whatever cpu_online_map
was at boot. When a new cpu is added to the system, the user is
unable to bind tasks to the new cpu -- in the code above we wind up
passing an empty cpumask to set_cpus_allowed and get -EINVAL.
Since cpuset_cpus_allowed already ensures that the cpumask it returns
reflects only online cpus, setting the default cpuset's cpus_allowed
mask to cpu_possible_map (which never changes) ensures correct
behavior.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
--- cpuhp-sched_setaffinity.orig/kernel/cpuset.c
+++ cpuhp-sched_setaffinity/kernel/cpuset.c
@@ -2041,7 +2041,7 @@ out:
void __init cpuset_init_smp(void)
{
- top_cpuset.cpus_allowed = cpu_online_map;
+ top_cpuset.cpus_allowed = cpu_possible_map;
top_cpuset.mems_allowed = node_online_map;
}
next prev parent reply other threads:[~2006-08-21 20:42 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 ` Nathan Lynch [this message]
2006-08-21 23:04 ` [PATCH] cpuset code prevents binding tasks to new cpus 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
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=20060821204251.GB9828@localdomain \
--to=ntl@pobox.com \
--cc=akpm@osdl.org \
--cc=anton@samba.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox