Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 02 Mar 1998 09:54:58 -0700
From:      Steve Passe <smp@csn.net>
To:        Open Systems Networking <opsys@mail.webspan.net>
Cc:        "John S. Dyson" <toor@dyson.iquest.net>, John Kelly <jak@cetlink.net>, current@FreeBSD.ORG
Subject:   Re: 3.0-RELEASE? 
Message-ID:  <199803021654.JAA28772@Ilsa.StevesCafe.com>
In-Reply-To: Your message of "Sun, 01 Mar 1998 22:41:23 EST." <Pine.BSF.3.95.980301223458.6402A-100000@orion.webspan.net> 

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

> > I think that the *biggest* and most complex thing that will be missing
> > will be the fine-grained SMP.  It seems that we'll have ELF support,
> > but I forget (or simply don't know) if we (they) decided that ELF will be
> > primary or not. 
> 
> I was hoping to see SMP (in ANY form), kernel threads, RAID, and
> softupdates, and maybe some TCP stuff, SACK, etc..
> But RAID, and SMP, and softupdates isn't bad.

I know this probably won't be good news for most, but I don't see SMP being
in 3.0:

  The way things are going now, it wont be anytime soon.  I don't expect to
  be able to participate again till late fall at the earliest.  No one else
  has stepped up to take over.

  The state it is in now is NOT release quality.  I don't think there is much
  finer grained locking to be had without MAJOR changes to the design,
  specifically the slpx() stuff needs to be replaced with critical sections
  protected by a mutex mechanism.  I played around with techniques for
  allowing both CPUs into the kernel at the same time with the current
  splx() design but it appears to be a loosing proposition.

  My suggestion (assumming no new major push REAL SOON) is to remove the
  SMP support from 3.0 and make a release out of it (when all other things
  are ready).  Then continue SMP efforts in 4.0  At the very least the 
  experimental things defined in smptests.h need to either be incorporated
  as default (most everything but PUSHDOWN_LEVELs 3 & 4), or removed
  entirely ie. PUSHDOWN_LEVELs 3 & 4.  These are my above mentioned attempts
  to allow both CPUs in simultaniously.  Its ugly code, and will never
  be 'right'.

--
Steve Passe	| powered by 
smp@csn.net	|            Symmetric MultiProcessor FreeBSD



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



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