Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761419AbYFDS3s (ORCPT ); Wed, 4 Jun 2008 14:29:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753101AbYFDS3l (ORCPT ); Wed, 4 Jun 2008 14:29:41 -0400 Received: from wolverine01.qualcomm.com ([199.106.114.254]:17208 "EHLO wolverine01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751756AbYFDS3j (ORCPT ); Wed, 4 Jun 2008 14:29:39 -0400 X-IronPort-AV: E=McAfee;i="5200,2160,5310"; a="3679116" Message-ID: <4846DF25.4020300@qualcomm.com> Date: Wed, 04 Jun 2008 11:29:57 -0700 From: Max Krasnyansky User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Paul Jackson CC: Andi Kleen , ioe-lkml@rameria.de, sivanich@sgi.com, a.p.zijlstra@chello.nl, linux-kernel@vger.kernel.org, kernel@kolivas.org, dfults@sgi.com, devik@cdi.cz, dino@in.ibm.com, emmanuel.pacaud@univ-poitiers.fr, deweerdt@free.fr, mingo@elte.hu, colpatch@us.ibm.com, nickpiggin@yahoo.com.au, rostedt@goodmis.org, oleg@tv-sign.ru, paulmck@us.ibm.com, menage@google.com, rddunlap@osdl.org, suresh.b.siddha@intel.com, tglx@linutronix.de Subject: Re: Inquiry: Should we remove "isolcpus= kernel boot option? (may have realtime uses) References: <20080601213019.14ea8ef8.pj@sgi.com> <1212446707.6269.26.camel@lappy.programming.kicks-ass.net> <48447C75.8040203@qualcomm.com> <200806030156.00155.ioe-lkml@rameria.de> <4844BB41.7000605@qualcomm.com> <4845D825.6000403@qualcomm.com> <20080603194148.56dfebe1.pj@sgi.com> <48461ADA.8020303@qualcomm.com> <877id5v1fg.fsf@basil.nowhere.org> <20080604124126.0d281a99.pj@sgi.com> In-Reply-To: <20080604124126.0d281a99.pj@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1295 Lines: 34 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. Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/