It would certainly be possible to have finer-grained locking. But the
cpuset code seems pretty happy with coarse-grained locking (only one
cpuset may be happy today. But, It will not be happy when there are tens
of other container subsystems use the same locks to protect their own
data structures. Using such coarse locking will certainly affect the
scalability.
All of this (and the rest of the snipped email with suggested
improvements) makes pretty good sense. But would it not be better
to do this in stages?
1) Split the code out from cpusets
2) Move to configfs
3) Work on locking scalability, etc ...
Else it'd seem that we'll never get anywhere, and it'll all be
impossible to review anyway. Incremental improvement would seem to
be a much easier way to fix this stuff, to me.
M.
-
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]
