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]
Message-ID: <4846EE4E.3030103@qualcomm.com>
Date:	Wed, 04 Jun 2008 12:34:38 -0700
From:	Max Krasnyansky <maxk@...lcomm.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC:	Paul Jackson <pj@....com>, Andi Kleen <andi@...stfloor.org>,
	ioe-lkml@...eria.de, sivanich@....com,
	linux-kernel@...r.kernel.org, kernel@...ivas.org, dfults@....com,
	devik@....cz, dino@...ibm.com, emmanuel.pacaud@...v-poitiers.fr,
	deweerdt@...e.fr, mingo@...e.hu, colpatch@...ibm.com,
	nickpiggin@...oo.com.au, rostedt@...dmis.org, oleg@...sign.ru,
	paulmck@...ibm.com, menage@...gle.com, rddunlap@...l.org,
	suresh.b.siddha@...el.com, tglx@...utronix.de
Subject: Re: Inquiry: Should we remove "isolcpus= kernel boot option? (may
 have realtime uses)



Peter Zijlstra wrote:
> On Wed, 2008-06-04 at 11:29 -0700, Max Krasnyansky wrote:
>> Paul Jackson wrote:
>>> Andi wrote:
>>>> Right now the system boot could put pages from some daemon in there before any 
>>>> cpusets are set up and there's no easy way to get them away again
>>> We (SGI) routinely handle that need with a custom init program,
>>> invoked with the init= parameter to the booting kernel, which
>>> sets up cpusets and then invokes the normal (real) init program
>>> in a cpuset configured to exclude those CPUs and nodes which we
>>> want to remain unloaded.  For example, on a 256 CPU, 64 node
>>> system, we might have init running on a single node of 4 CPUs,
>>> and leave the remaining 63 nodes and 252 CPUs isolated from all
>>> the usual user level daemons started by init.
>>>
>>> There is no need for additional kernel changes to accomplish this.
>> You do not even need to replace /sbin/init for this, no ?
>> Simply installing custom
>> 	/etc/init.d/create_cpusets
>> with priority 0
>> 	# chkconfig: 12345 0 99
>> will do the job.
>>
>> That script will move init itself into the appropriate cpuset and from then on
>> everything will inherit it.
> 
> The advantage of using a replacement /sbin/init is that you execute
> before the rest of userspace, unlike what you propose.
That does not matter for the cpu placement (ie the end result is the same) but
does matter for memory placement as PaulJ pointed out.

Thanx
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ