Re: cpusets not cpu hotplug aware

[Anton Blanchard]

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.

> 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).

Anton
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/