From owner-freebsd-arch@FreeBSD.ORG Sat Jun 11 22:54:09 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 C557F106564A; Sat, 11 Jun 2011 22:54:09 +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 0A5FC8FC08; Sat, 11 Jun 2011 22:54:08 +0000 (UTC) Received: by wwc33 with SMTP id 33so3750710wwc.31 for ; Sat, 11 Jun 2011 15:54:08 -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:content-type :content-transfer-encoding; bh=iPFC7eba6Pv7br9fE70/PUUo6ppNu3xXYXhWwUyCEMQ=; b=tv1Bk6EKyP5qwzPN8mDJfq1gmwHgBmA3PXZw009qm2+jgsfhpht0wVq5lWEGOduum/ kykZ+TjlE1EQ+DL2z0lz1n34orNBK/3sIBU7DSVZC+boxNwi6e5Lw0L4YN13PLS3fxl/ 16Wer9lsAtw0GelRMl9Ak5sMYkhXw9pcrCMiw= 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:content-type :content-transfer-encoding; b=lbw/GQfb4kAvASpBR6lpwbM+LCkW4Kj7G/mcMuphrI7rU0vEUQl5mWL29pfhS4nP9o UHwGBdxI2Vdhr6iMlA6TnDhkV76i20Ygb0rpCgEF13RLJZ5T0wXHIdGZFEfRDDHw8leI HWBRF2/F2zpzWn2X6HhrJwwJ+jg+xilmcgdbE= MIME-Version: 1.0 Received: by 10.216.209.212 with SMTP id s62mr3462667weo.67.1307832847902; Sat, 11 Jun 2011 15:54:07 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.216.52.141 with HTTP; Sat, 11 Jun 2011 15:54:07 -0700 (PDT) In-Reply-To: <20110611204326.GA51320@zim.MIT.EDU> References: <20110611171834.GA38142@zim.MIT.EDU> <20110611204326.GA51320@zim.MIT.EDU> Date: Sat, 11 Jun 2011 15:54:07 -0700 X-Google-Sender-Auth: l5SjN7t0-Dgbx4mmSwaQrxehpro Message-ID: From: mdf@FreeBSD.org To: mdf@freebsd.org, Adrian Chadd , freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 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 22:54:10 -0000 On Sat, Jun 11, 2011 at 1: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. With the specific set we have at $WORK it seems fine. IIRC, Giant is held when the module's init function is called, but it's dropped during sleep so there's still some parallelism that can be achieved -- I would guess most driver init is essentially instant on fast modern CPUs except when waiting for device probes, etc. Cheers, matthew >> > OS X has an interesting solution, intended to preserve the >> > flexibility of dynamic modules, while minimizing boot time. >> > It provides a kextcache utility, which packages the kernel >> > and all of the needed modules into a single binary for better >> > locality on disk. =A0Unlike recompiling the kernel, running >> > kextcache is fast, and the system runs it automatically when >> > hardware or driver changes necessitate it. >> >> This would be interesting -- isn't it essentially a re-link of the >> kernel + modules? > > They actually go further than that and "pre-bind" the modules, > essentially doing the work of the dynamic linker ahead of time. > I have doubts that this trick saves much time. =A0It also doesn't > address Doug's concern about the overhead of the additional level > of indirection needed for dynamic symbols; however, that overhead > probably isn't significant either. >