From owner-freebsd-smp  Thu Sep 12 23:41:59 1996
Return-Path: owner-smp
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id XAA25154
          for smp-outgoing; Thu, 12 Sep 1996 23:41:59 -0700 (PDT)
Received: from uruk.org (uruk.org [198.145.95.253])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA25142
          for <freebsd-smp@freebsd.org>; Thu, 12 Sep 1996 23:41:50 -0700 (PDT)
From: erich@uruk.org
Received: from loopback (loopback [127.0.0.1]) by uruk.org (8.7.4/8.7.3) with SMTP id XAA14603; Thu, 12 Sep 1996 23:39:33 -0700 (PDT)
Message-Id: <199609130639.XAA14603@uruk.org>
X-Authentication-Warning: uruk.org: Host loopback [127.0.0.1] didn't use HELO protocol
To: Terry Lambert <terry@lambert.org>, smp@csn.net (Steve Passe)
cc: peter@spinner.dialix.com, rv@groa.uct.ac.za, freebsd-smp@freebsd.org
Subject: Re: Intel XXpress - some SMP benchmarks 
In-reply-to: Your message of "Thu, 12 Sep 1996 14:42:50 PDT."
             <199609122142.OAA07599@phaeton.artisoft.com> 
Date: Thu, 12 Sep 1996 23:39:32 -0700
Sender: owner-smp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


Terry Lambert <terry@lambert.org> writes:

> > if we have sparse tables, ie 16 entries (most of which will be empty), code
> > like the following becomes very inefficient:
> > 
> > #ifdef SMP
> > 			for (j = i = 0; i < SPARSE_TABLE_SIZE; i++) {
> > 				if (p == SMPcurproc[i])
> > 					j++;
> > 			}
> > ...
> 
> Use it like a hash:
> 
> #ifdef SPARSE
> int	cpuid[ MAX_CPUID];	/* filled out by probe sequence*/
> #define	CPUID(x)	(cpuid[ x])
> #else	/* !SPARSE*/
> #define	CPUID(x)	(x)
> #endif	/* !SPARSE*/
> 
> Obviously, this would save one indirection per reference, which shouldn't
> be too frequent anyway.

I use a virtual CPU mapping scheme which is:

  --  BSP -> virtual number 0
  --  others mapped consecutively from there  (doesn't really matter which
	order, but I use APIC id order).

Well, the way I'm doing it now in the code I'm writing is something
like:

	int  apic_to_virtual[MAX_APIC_ID];
	int  virtual_to_apic[MAX_CPUS];
	#define CPUNUM(x)  (cpunum[x])
	#define CUR_CPUNUM()  (cpunum[cur_apicid()])

The APIC register reference takes so long that the array reference is
simply absorbed in the overhead.  I always get the virtual number (and
possibly the APIC id, if necessary), then operate from there.

Walking a sparse array takes up enough other overhead (checking for
whether you're done as well as not using non-existent entries)
that translating back to the actual APIC ID is OK.  If anything it
simplifies the code to walk only consecutive numbers.

--
  Erich Stefan Boleyn                 \_ E-mail (preferred):  <erich@uruk.org>
Mad Genius wanna-be, CyberMuffin        \__      (finger me for other stats)
Web:  http://www.uruk.org/~erich/     Motto: "I'll live forever or die trying"