"one that caters the general purpose OS" ... a tad terse on the
documentation ;).
I guess what you have is a new cpumask_t cpu_system_map, which is the
union of the CPUs of all the cpusets marked 'system', where to a rough
approximation the CPUs -not- in that cpumask are what we would have
called the isolated CPUs by the old code?
In any case, if this patch survives its birth, it will need an added
change for some file in the Documentation directory.
Could we get the term 'cpu' in the name 'system' somehow? Perhaps call
this new cpuset flag 'cpus_system' or some such. Cpusets handles both
CPU and memory configuration, and I make some effort to mark per-cpuset
specific attributes that apply to only one of these with a prefix
indicating to which they apply. The per-cpuset flag name 'system', by
itself, would mean little to someone just listing the files in a cpuset
directory.
In the rebuild_system_map() code, you have:
+ if (cpus_empty(*new_system_map))
+ BUG();
... what's to prevent simply turning off the 'system' (aka cpus_system)
in the top cpuset, on a system with only that one cpuset, and hitting
this BUG()?
Overall I like this approach. I suspect you made a good choice in
marking the non-isolated (aka system) CPUs, rather than the isolated
CPUs. It seems clearer that way, in understanding the affects of
overlapping cpusets with various markings.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.940.382.4214
--
