From owner-freebsd-current Mon Mar 2 08:55:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA07971 for freebsd-current-outgoing; Mon, 2 Mar 1998 08:55:29 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA07941 for ; Mon, 2 Mar 1998 08:55:22 -0800 (PST) (envelope-from fbsd@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id JAA28772; Mon, 2 Mar 1998 09:54:58 -0700 (MST) Message-Id: <199803021654.JAA28772@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Open Systems Networking cc: "John S. Dyson" , John Kelly , current@FreeBSD.ORG Subject: Re: 3.0-RELEASE? In-reply-to: Your message of "Sun, 01 Mar 1998 22:41:23 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Mar 1998 09:54:58 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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