From owner-freebsd-audit Sat Jul 14 13:23:13 2001 Delivered-To: freebsd-audit@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id D9BB737B401; Sat, 14 Jul 2001 13:23:07 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from wonky.feral.com (wonky.feral.com [192.67.166.7]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f6EKN6S89387; Sat, 14 Jul 2001 13:23:06 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Sat, 14 Jul 2001 13:22:53 -0700 (PDT) From: Matthew Jacob Reply-To: To: Alfred Perlstein Cc: , Subject: Re: planned change to mbinit code and minor changes to mp startup In-Reply-To: <20010714151902.A15299@sneakerz.org> Message-ID: <20010714132021.G29314-100000@wonky.feral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 > > 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. Okay. Thanks for the review! I like your approach better except for the fact it consumes more resources by creating resource maps and locks for non-existent CPUs. > Lastly, the functions to set mp_ncpus to 1 should be in > machine independant code for non-SMP boxes. Can you say a bit more about what you mean here? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message