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.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
-
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]
