From owner-freebsd-smp Sat Jul 14 14:59:30 2001 Delivered-To: freebsd-smp@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id 9B48037B403; Sat, 14 Jul 2001 14:59:22 -0700 (PDT) (envelope-from bright@sneakerz.org) Received: by sneakerz.org (Postfix, from userid 1092) id E12825D010; Sat, 14 Jul 2001 16:59:11 -0500 (CDT) Date: Sat, 14 Jul 2001 16:59:11 -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: <20010714165911.B15299@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-smp@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. Ok, on second thought, the patch isn't that bad of an idea, however: > Index: kern/subr_mbuf.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/subr_mbuf.c,v > retrieving revision 1.2 > diff -u -r1.2 subr_mbuf.c > --- kern/subr_mbuf.c 2001/06/22 16:03:23 1.2 > +++ kern/subr_mbuf.c 2001/07/14 18:14:30 > @@ -57,12 +62,11 @@ > #endif > > /* > - * SMP and non-SMP kernels clearly have a different number of possible cpus. > */ > #ifdef SMP > -#define NCPU_PRESENT mp_ncpus > +#define CPU_ABSENT(x) ((all_cpus & (1 << x)) == 0) > #else > -#define NCPU_PRESENT 1 > +#define CPU_ABSENT(x) 0 > #endif > > /* This should be in some file where other "per cpu" systems can get at it, duplicating it everywhere is gross. (for instance, my cpu affinity patches). Also, since it looks like this would break if we suddently started up another CPU I really don't agree with not populating the pools if 'CPU_ABSENT(i)'. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message