From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 28C14DDF33 for ; Mon, 21 Apr 2008 12:04:07 +1000 (EST) Subject: Re: [PATCH 2.6.26?] Raise the upper limit of NR_CPUS. From: Benjamin Herrenschmidt To: Tony Breeds In-Reply-To: <20080418053349.GE20457@bakeyournoodle.com> References: <20080418053349.GE20457@bakeyournoodle.com> Content-Type: text/plain Date: Mon, 21 Apr 2008 12:03:47 +1000 Message-Id: <1208743427.10486.2.camel@pasglop> Mime-Version: 1.0 Cc: LinuxPPC-dev , Paul Mackerras Reply-To: benh@kernel.crashing.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 2008-04-18 at 15:33 +1000, Tony Breeds wrote: > As the pacas are statically initialised increasing NR_CPUS beyond 128, > means that any additional pacas will be empty ... which is bad. > > This patch adds the required functionality to fill in any excess pacas > at runtime. > > Signed-off-by: Tony Breeds > --- > I know it's late, but can this be considered for 2.6.26? NAK. You must NEVER manipulate kernel globals from prom_init.c. The fact that prom_init is linked with the kernel is an "accident" which may change. Your scheme would break among others with kexec or non-OF bootloaders Ben.