From owner-freebsd-arch@FreeBSD.ORG Sun Jun 12 02:09:27 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 E4536106564A; Sun, 12 Jun 2011 02:09:26 +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 926B78FC12; Sun, 12 Jun 2011 02:09:26 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5C24JJ7058553 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 11 Jun 2011 20:04:19 -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 20:04:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110611171834.GA38142@zim.MIT.EDU> <20110611204326.GA51320@zim.MIT.EDU> To: mdf@FreeBSD.org 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 20:04:19 -0600 (MDT) Cc: David Schultz , Adrian Chadd , 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: Sun, 12 Jun 2011 02:09:27 -0000 On Jun 11, 2011, at 6:00 PM, mdf@FreeBSD.org wrote: > On Sat, Jun 11, 2011 at 4:07 PM, Warner Losh wrote: >>=20 >> On Jun 11, 2011, at 2:43 PM, David Schultz wrote: >>=20 >>> On Sat, Jun 11, 2011, mdf@freebsd.org wrote: >>>> On Sat, Jun 11, 2011 at 10:18 AM, David Schultz = wrote: >>>>> On Sat, Jun 11, 2011, Adrian Chadd wrote: >>>>>> Hi guys, >>>>>>=20 >>>>>> Has there been any further thought as of late about shipping = kernels >>>>>> with modules only by default, rather than monolithic kernels? >>>>>>=20 >>>>>> I tried this experiment a couple years ago and besides a little >>>>>> trickery with ACPI module loading, it worked out fine. >>>>>>=20 >>>>>> Is there any reason we aren't doing this at the moment? Eg by = having a >>>>>> default loader modules list populated from the kernel config = file? >>>>>=20 >>>>> I've been doing this for years, and it has come in quite handy. >>>>> For instance, when my if_msk gets wedged, the only way to fix it >>>>> short of rebooting seems to be reloading the driver. >>>>>=20 >>>>> One issue, however, is that the boot loader is horrendously slow >>>>> at loading modules. (Either that or my BIOS has a braindead int = 13h >>>>> handler.) Most of these modules aren't actually needed until much >>>>> later in the boot process, so a mechanism to load non-essential >>>>> modules after the file systems are mounted might provide a good >>>>> solution. >>>>=20 >>>> 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 >> Loading isn't the problem. The timeouts that you are waiting for are = part of the probe/attach sequence. And that's strictly serialized... >>=20 >=20 > If the timeouts are implemented using sleep(9) then Giant is dropped > while waiting for a timeout, and another driver can begin its > initialization. Thus the time to load all modules becomes roughly the > max of all the timeouts, rather than the sum. Except for the whole single threaded nature of all the bus drivers, this = might work. Making them multi-threaded is a lot of work, and likely = won't result in significant gains. The timeouts people complain about = are already all done in parallel at the end anyway. Warner=