linux-kernel - Re: Using cpusets for configuration/isolation [Was Re: RT sched: cpupri_vec lock contention with def_root

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 19 Nov 2008 12:01:47 -0800
From:	Max Krasnyansky <maxk@...lcomm.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Nish Aravamudan <nish.aravamudan@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Gregory Haskins <ghaskins@...ell.com>,
	Dimitri Sivanich <sivanich@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Using cpusets for configuration/isolation [Was Re: RT sched:
 cpupri_vec lock contention with def_root_domain and no load balance]

Ingo Molnar wrote:
> * Max Krasnyansky <maxk@...lcomm.com> wrote:
> 
>> Ingo Molnar wrote:
>>> * Max Krasnyansky <maxk@...lcomm.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/