From owner-freebsd-arch@FreeBSD.ORG Sun Jun 12 00:00:24 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 CF665106564A; Sun, 12 Jun 2011 00:00:23 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2DCDD8FC16; Sun, 12 Jun 2011 00:00:22 +0000 (UTC) Received: by wwc33 with SMTP id 33so3768176wwc.31 for ; Sat, 11 Jun 2011 17:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=b9xhvmWxpICLZI6oW7xybJ73PzCUh0VXz1Lu3zh7q+o=; b=wDZdCBh1VeYCWubxGRis+CSZfZ1njeUHq/BT2ZrdPHTHYegQXAUjnVf7gHDsIWvQsZ Ire1cppq/rTAEydxJCnA1MRIMQjuyU2KykfrXZ+2X4Vc35yNt8uKcehjVRbCWDmxeB/m bhFzFrFR2LJjU/jg5lL4CuurvcV78s5P55w/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=NnyK1/lSAvKfzEDSNCINjFgNYL527iy0MdcdCoDIPUD3OF4+cq8Ol5/F/aUmSuu+XY Dszu9AI0wHl5+8AfxCZcmksSuyzFHnhtxnK66ULyZiuRx15nMMBgeFEkvyvCs6dMfDCs cOZJbamFdt8rw2YYbKW8imjc9cvu1jdSXnHaE= MIME-Version: 1.0 Received: by 10.216.221.67 with SMTP id q45mr1093039wep.97.1307836821753; Sat, 11 Jun 2011 17:00:21 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.216.52.141 with HTTP; Sat, 11 Jun 2011 17:00:21 -0700 (PDT) In-Reply-To: References: <20110611171834.GA38142@zim.MIT.EDU> <20110611204326.GA51320@zim.MIT.EDU> Date: Sat, 11 Jun 2011 17:00:21 -0700 X-Google-Sender-Auth: Zk9zV-OUhPC7elxqapBDIQ2lM8k Message-ID: From: mdf@FreeBSD.org To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 00:00:24 -0000 On Sat, Jun 11, 2011 at 4:07 PM, Warner Losh wrote: > > On Jun 11, 2011, at 2:43 PM, David Schultz wrote: > >> 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, >>>>> >>>>> Has there been any further thought as of late about shipping kernels >>>>> with modules only by default, rather than monolithic kernels? >>>>> >>>>> I tried this experiment a couple years ago and besides a little >>>>> trickery with ACPI module loading, it worked out fine. >>>>> >>>>> 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? >>>> >>>> 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. >>>> >>>> One issue, however, is that the boot loader is horrendously slow >>>> at loading modules. =A0(Either that or my BIOS has a braindead int 13h >>>> handler.) =A0Most 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. >>> >>> Indeed, at $WORK we're trying to get shutdown -> restart under 2 >>> minutes. =A0Several 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. >> >> Have you found that drivers can be reliably loaded in parallel >> these days? =A0I'm always waiting for timeouts on four card readers >> and two optical drives, so that would be a big win for me. =A0IIRC, >> nothing can happen in parallel during boot because the scheduler >> is initialized very late in the process. =A0I'm not a device driver >> person, but I imagine there might be other assumptions that might >> get in the way as well. > > Loading isn't the problem. =A0The timeouts that you are waiting for are p= art of the probe/attach sequence. =A0And that's strictly serialized... > 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. Cheers, matthew