Messages in this thread | | | Date | Wed, 27 Feb 2008 17:39:58 -0600 | From | Paul Jackson <> | Subject | Re: [RFC/PATCH 2/4] cpuset: system sets |
| |
Peter wrote: > A system set will be one that caters the > general purpose OS. This patch provides the infrastructure, but doesn't > actually provide any new functionality. > > Typical functionality would be setting the IRQ affinity of unbound IRQs to > within the system set. And setting the affinity of unbounded kernel threads to > within the system set.
"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
| |