Messages in this thread |  | | | Date | Wed, 27 Feb 2008 17:53:56 -0800 | | From | Max Krasnyanskiy <> | | Subject | Re: [RFC/PATCH 2/4] cpuset: system sets | |
Paul Jackson wrote:
> 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?
Yes it's in fact exactly the same as ~cpu_isolated_map in the patches that I
sent out earlier.
> In any case, if this patch survives its birth, it will need an added
> change for some file in the Documentation directory.
Sure. We can just update readme from my patch to use cpuset instead of
/sys/system/cpu/cpu1/isolated bits. If we go with this approach that is.
> 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.
Makes sense to me too. ie cpus_system is more descriptive.
> 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()?
Good point.
> 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.
Ok so you did not like the 'isolated' name too ;-).
Max
|  |