From owner-cvs-all Mon Mar 11 9: 5:58 2002 Delivered-To: cvs-all@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 0073237B417 for ; Mon, 11 Mar 2002 09:05:47 -0800 (PST) Received: (qmail 22859 invoked from network); 11 Mar 2002 17:05:45 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Mar 2002 17:05:45 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2BH63v22283; Mon, 11 Mar 2002 12:06:03 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200203102058.g2AKvum00955@mass.dis.org> Date: Mon, 11 Mar 2002 12:05:45 -0500 (EST) From: John Baldwin To: Michael Smith Subject: Re: cvs commit: src/sys/sys smp.h src/sys/kern subr_smp.c src/sy Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jeff Roberson , Doug Rabson , Jeff Roberson Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 10-Mar-02 Michael Smith wrote: >> > This screws up the SMP probe for ia64 because the information which >> > cpu_mp_probe() uses isn't available until after cpu_startup() is called >> > (i.e. SI_SUB_CPU:SI_ORDER_FIRST). The code in the ia64 platform which >> > detects SMP can't (currently) run before the VM system is started... >> >> Is it possible to do it at all before the VM starts up? This really >> throws a wrench in my uma plans. Can you even tell how many cpus you have >> before then? If you can do this, and force your cpu ids to be virtual and >> non sparse, then you can set mp_maxid to the number of cpus. > > The CPU ID array should be "reasonably dense". > > On systems where the CPU ID space is sparse, a "dense to sparse" > translation can be performed relatively cheaply. > > You're causing massive (bad) upheaval in the system for the sake of > supporting a poor design choice. Instead, just shift the CPU ID paradigm > back to where it was. > > In many cases (IA64 is one of them), CPUs other than the boot processor > may be detected and started up at any time. You want a constant that > allows the maximum number of CPUs supported by the platform, rather than > to detect the number of CPUs currently on the platform; just pick a sane > upper bound (eg. 8) and work with it for now. MAXCPU does this. I agree that I would like to depend on this and CPU_ABSENT() rather than on cpu_maxid. Even when using cpu_maxid, you still need to use CPU_ABSENT to account for sparseness. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message