From owner-cvs-all@FreeBSD.ORG Thu Jan 26 15:18:38 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EE9B16A420; Thu, 26 Jan 2006 15:18:38 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C3B943D60; Thu, 26 Jan 2006 15:18:27 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 7032007 for multiple; Thu, 26 Jan 2006 10:17:17 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0QFIPwD042644; Thu, 26 Jan 2006 10:18:26 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Scott Long Date: Thu, 26 Jan 2006 10:19:18 -0500 User-Agent: KMail/1.9.1 References: <200601260957.k0Q9vCUn054132@repoman.freebsd.org> <200601260948.21491.jhb@freebsd.org> <43D8E2E5.5060309@samsco.org> In-Reply-To: <43D8E2E5.5060309@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601261019.21556.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1252/Thu Jan 26 06:03:25 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Murray Stokely , cvs-doc@freebsd.org, cvs-all@freebsd.org, Robert Watson , Ceri Davies , doc-committers@freebsd.org Subject: Re: cvs commit: www/en/releases/6.1R todo.sgml X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 15:18:38 -0000 On Thursday 26 January 2006 09:55, Scott Long wrote: > John Baldwin wrote: > > On Thursday 26 January 2006 07:27, Robert Watson wrote: > >>On Thu, 26 Jan 2006, Ceri Davies wrote: > >>>On Thu, Jan 26, 2006 at 09:57:12AM +0000, Murray Stokely wrote: > >>>>murray 2006-01-26 09:57:12 UTC > >>>> > >>>> FreeBSD doc repository > >>>> > >>>> Modified files: > >>>> en/releases/6.1R todo.sgml > >>>> Log: > >>>> Add kbdmux and sysinstall smp kernel install items from the ideas > >>>> page to the 6.1 Desired Features list. > >>> > >>>I think it's a little late to mess with sysinstall to that extent for > >>>6.1. Sounds like the kind of thing that could sit in -CURRENT for > >>> months, but hardly anyone would actually be using it. It seems that > >>> the main problem with sysinstall is that hardly any of our developers > >>> use it. > >>> > >>>On to the question: how often does an SMP kernel fail to boot where a UP > >>>one might work? I remember that this used to be a problem, but if it's > >>>still "too often", can we have just the bits that probe for an mptable > >>>(or however we determine that there is more that one processor) in the > >>> UP kernel without suffering that instability? > >>> > >>>What I'm basically asking is how much of the SMP code is really required > >>>just to detect MP hardware? > >> > >>SMP kernels now pretty much universally run on UP systems, thanks to work > >>John did a couple of years ago. The problem has historically been a > >>performance once: the overhead of all the atomic instructions to run an > >> SMP kernel on a UP system is significant. We're working gradually to > >> improve that, but it's still quite noticeable. There has been talk of > >> run-time compiling/relinking to use different versions of mutexes (and > >> all that), but no progress as far as I know. I can't speak to how much > >> information the loader has/needs to decide if it should auto-load an SMP > >> kernel. A simpler version of the world says that you have an SMP kernel > >> in sysinstall, and based on it probing CPUs, it sets the default kernel > >> in the install to GENERIC or SMP. > > > > Yes, I would very much prefer that the install just use an SMP kernel. > > Note that on all the non-i386 architectures we just have SMP on in > > GENERIC if it is supported. > > SMP kernels still do not universally work on all i386 machines. I know > that Alpha and Sparc hardware was designed from the ground up to support > SMP, instead of being a bolted on hack like with x86, but that doesn't > change the facts of the situation. Despite your work, I don't think it > will ever be safe to make SMP be the default on x86. Huh? Which machines do they not work on? Actually, many of the problems people had with APIC enabled in 6.0 were solved by using an SMP kernel. Not to mention the fact that one can always disable APIC via hints. Also, speaking of x86, SMP is _already_ the default on amd64. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org