Re: Using cpusets for configuration/isolation [Was Re: RT sched: cpupri_vec lock contention with def_root_domain and no load balance]

[Max Krasnyansky <maxk@qualcomm.com>]

Ingo Molnar wrote:
> * Max Krasnyansky <maxk@qualcomm.com> wrote:
> 
>> Ingo Molnar wrote:
>>> * Max Krasnyansky <maxk@qualcomm.com> wrote:
>>>
>>>> What you described is almost exactly what I did in my original 
>>>> cpu isolation patch, which did get NAKed :). Basically I used 
>>>> global cpu_isolated_map and exposed 'isolated' bit, etc.
>>> Please extend cpusets according to the plan outlined by PeterZ a 
>>> few months ago - that's the right place to do partitioning.
>> Already did. It's all in mainline. The part you quoted was just 
>> pointing out that the original approach was not correct.
> 
> Yeah, we have bits of it (i merged them, and i still remember them ;-) 
> - but we still dont have the "system set" concept suggested by Peter 
> though. We could go further and make it really easy to partition all 
> scheduling and irq aspects of the system via cpusets.

Actually we (or maybe just me) gave up on those for now. We went back an forth
on the 'system set' and what it supposed to mean. Both Paul J. and Paul M.
were against the concept and especially backward compatibility with existing
user-space tools that use cpusets. Plus it's really really easy to setup the
'system' set from user-space and I just ended up writing 'syspart' thing that
I mentioned before.

Similar thing happened to "managing irqs via cpusets" idea. Peter and I wanted
to represent them ask tasks and Paul J. was very vocally :) opposed to it.
What we settled on was that we will manage irqs via proc for now. I added a
notion of 'default' irq affinity (ie /proc/irq/default_smp_affinity) which is
already in mainline.

We can probably revisit irq management and 'system' cpuset again. At this
point I'm swamped with other stuff though.

Max