From owner-freebsd-audit Sat Jul 14 13:19:22 2001 Delivered-To: freebsd-audit@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id 30FA437B401; Sat, 14 Jul 2001 13:19:13 -0700 (PDT) (envelope-from bright@sneakerz.org) Received: by sneakerz.org (Postfix, from userid 1092) id B2D395D010; Sat, 14 Jul 2001 15:19:02 -0500 (CDT) Date: Sat, 14 Jul 2001 15:19:02 -0500 From: Alfred Perlstein To: Matthew Jacob Cc: smp@freebsd.org, audit@freebsd.org Subject: Re: planned change to mbinit code and minor changes to mp startup Message-ID: <20010714151902.A15299@sneakerz.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mjacob@feral.com on Sat, Jul 14, 2001 at 11:25:46AM -0700 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Matthew Jacob [010714 13:26] wrote: > > Problem: the MB init and alloc code assumes that in the SMP case that there is > a dense array of CPU ids for the CPUs present and reported via mp_ncpus. > > This is not true and cannot be true for a number of reasons: > > a) CPUids don't always start at 0 (e.g, Alpha 8200) > b) CPUs may be disabled, leaving holes in the map. > c) CPUs may (eventually) want to come and go while we're running. > > I thought about making cpuid a 'virtual' construct. We may eventually want to > do this, but this only solves #a/#b- it will not move us toward #c. And it can > get somewhat dicey for the amount of code to check and change by doing this. > > Below is a partial solution that takes the approach of just checking who is > 'absent' when mbinit is called. It requires that all_cpus be set sensibly > whether there are more than one cpu or not (which makes sense too). > > Making this change allows the ALpha 8200s to work again and also allows > disabling arbitrary CPUs leaving holes in the CPU map to work without getting > out of sync. No, this patch is a very bad idea for the simple reason that it makes the mbuf allocator figure out which cpus are absent. The mbuf subsystem shouldn't look for holes/sparseness in the number of cpus. The correct thing is to make "mp_ncpus" equal to the max amount of CPUs in the system, then everything will work properly, not onlt that but if you ever get a machine with hot swap cpus you can easily spin up another CPU while running without issues. Lastly, the functions to set mp_ncpus to 1 should be in machine independant code for non-SMP boxes. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message