Re: cpusets not cpu hotplug aware

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux