Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Jul 2001 15:19:02 -0500
From:      Alfred Perlstein <bright@sneakerz.org>
To:        Matthew Jacob <mjacob@feral.com>
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>
In-Reply-To: <Pine.BSF.4.21.0107141117110.87022-100000@beppo>; from mjacob@feral.com on Sat, Jul 14, 2001 at 11:25:46AM -0700
References:  <Pine.BSF.4.21.0107130000220.61694-100000@beppo> <Pine.BSF.4.21.0107141117110.87022-100000@beppo>

next in thread | previous in thread | raw e-mail | index | archive | help
* Matthew Jacob <mjacob@feral.com> [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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010714151902.A15299>