Nathan wrote:
> # echo 1 > /sys/devices/system/cpu/cpu3/online
> # taskset 0x8 foo
>
> has a race condition, depending on your kernel's configuration.
Good point. That's not a nice race to force on users.
I relent -- not udev.
> Maybe the cpuset code should just stay out of the way unless the admin
> has instantiated one?
I really don't like where such special case, modal behaviour leads us.
Let's say we have two systems, side by side. Both have been up for
many months. On one of these systems, one time, a few months ago, the
sysadmin briefly made and removed a cpuset:
mkdir /dev/cpuset
mount -t cpuset cpuset /dev/cpuset
mkdir /dev/cpuset/foo
rmdir /dev/cpuset/foo
umount /dev/cpuset
rmdir /dev/cpuset
On the other of these systems, the sysadmin never did any such thing.
These two systems are now identical in every other aspect that might
matter to this discussion.
The sched_setaffinity call should behave the same on these two systems.
If the kernel has to impose a trivial bit of policy (such as forcing
the top cpuset to track what's online) in order to provide uniformally
consistent (not modal) and race free behaviour, then it should.
And besides, as someone else noted, it's alot easier than dealing with
udev ;).
Conclusion - the kernel should simply force the top_cpuset to track the
online maps. See further my response to your patch.
--
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]
