From owner-cvs-doc@FreeBSD.ORG Thu Jan 26 15:14:00 2006 Return-Path: X-Original-To: cvs-doc@FreeBSD.org Delivered-To: cvs-doc@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA75E16A420; Thu, 26 Jan 2006 15:14:00 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08EFD43D46; Thu, 26 Jan 2006 15:13:59 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k0QFDw3g038193; Thu, 26 Jan 2006 08:13:59 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43D8E73E.4050103@samsco.org> Date: Thu, 26 Jan 2006 08:14:06 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ceri Davies References: <200601260957.k0Q9vCUn054132@repoman.freebsd.org> <20060126101706.GJ36965@submonkey.net> In-Reply-To: <20060126101706.GJ36965@submonkey.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Murray Stokely , cvs-doc@FreeBSD.org, cvs-all@FreeBSD.org, doc-committers@FreeBSD.org Subject: Re: cvs commit: www/en/releases/6.1R todo.sgml X-BeenThere: cvs-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the doc and www trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 15:14:00 -0000 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? > > Ceri As in my other post, I don't think it will ever be safe to make i386 default to an SMP kernel (not counting the performance arguments which are also relevant). Anyways, as far as this TODO task goes, the first step is to simply update the release makefiles to generate both a UP and SMP kernel and have them both get installed, one as /boot/kernel and the other as /boot/kernel.SMP. That overcomes the first hurdle for lowering the SMP bar for users, as then it would be quite easy to add a bootloader menu item to select one kernel or the other. The next step would be add an mptable parser to sysinstall (not as hard as it sounds, probably about 100 lines of code at most) and have sysinstall either automatically rename /boot/kernel.SMP to /boot/kernel as needed, or give the user the choice on renaming. The only problem here is that most MPTables don't recognize hyperthreading. So either we live with that, or we take extra steps to parse ACPI tables. Since we do have ACPI on by default, this also isn't as hard as it sounds. I don't want SMP enabled by default on i386, not even for the installation kernel. It will cause a regression in the amount of systems that we support, and it will impact performance. Neither of these are desirable. Making detection and installation more automated is a very good thing, though, and that's why this is a TODO item. There is still time to work on this before the 6.1 release, and we can always back it out if it doesn't work out at first. So yes, I encourage people to work on this. Scott