Re: [RFC/PATCH 2/4] cpuset: system sets

[Max Krasnyanskiy <maxk@qualcomm.com>]

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