From owner-freebsd-arch@FreeBSD.ORG Sat Jun 11 23:09:30 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB43F106564A; Sat, 11 Jun 2011 23:09:30 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A665C8FC16; Sat, 11 Jun 2011 23:09:30 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5BN8pUf057709 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 11 Jun 2011 17:08:51 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 11 Jun 2011 17:08:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9349A935-F13D-4265-A59C-C1E9B35F2B73@bsdimp.com> References: <20110611171834.GA38142@zim.MIT.EDU> <20110611204326.GA51320@zim.MIT.EDU> To: "K. Macy" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 11 Jun 2011 17:08:51 -0600 (MDT) Cc: mdf@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] shipping kernels with default modules? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 23:09:31 -0000 On Jun 11, 2011, at 2:49 PM, K. Macy wrote: >>> Indeed, at $WORK we're trying to get shutdown -> restart under 2 >>> minutes. Several seconds of this is moving things *into* the kernel >>> that need to be there (disk drivers), and everything else to a point >>> in init where modules can be loaded in parallel, using the faster = disk >>> driver, rather than in serial with slow BIOS handlers. >>=20 >> Have you found that drivers can be reliably loaded in parallel >> these days? I'm always waiting for timeouts on four card readers >> and two optical drives, so that would be a big win for me. IIRC, >> nothing can happen in parallel during boot because the scheduler >> is initialized very late in the process. I'm not a device driver >> person, but I imagine there might be other assumptions that might >> get in the way as well. >=20 > Although I imagine that many drivers silently benefit from being > loaded serially, to the best of my knowledge there is nothing > architecturally requiring this apart from the fact that the scheduler > isn't started until everything else tied to initialization happens. > The absence of any sort of preemption was a bit of a thorn in my side > back when I was working on "xenbus", as the linux implementation > relies on the use of multiple thread contexts. I don't know how much > effort to date has been put in to making boot fast. Right now newbus uses Giant for all its locking. That's the biggest = problem preventing parallel probe/attach. Also, each and every bus = calls probe, then calls attach for each device in sequence. Fixing that = would require changing all the bus drivers. Warner=