Date: Sat, 11 Jun 2011 17:00:21 -0700 From: mdf@FreeBSD.org To: Warner Losh <imp@bsdimp.com> Cc: David Schultz <das@freebsd.org>, Adrian Chadd <adrian@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: [RFC] shipping kernels with default modules? Message-ID: <BANLkTikCg_yOXEmFASFZQY3xOuT9o5%2Bcdw@mail.gmail.com> In-Reply-To: <D721F18A-6ACB-4AB5-83FD-DB23D62BF5D3@bsdimp.com> References: <BANLkTin2AwKRT7N6HWqBctJcT72_mR=Otg@mail.gmail.com> <20110611171834.GA38142@zim.MIT.EDU> <BANLkTik=z-fb1sDwh0dr4hRWmdhLMWiKdw@mail.gmail.com> <20110611204326.GA51320@zim.MIT.EDU> <D721F18A-6ACB-4AB5-83FD-DB23D62BF5D3@bsdimp.com>
index | next in thread | previous in thread | raw e-mail
On Sat, Jun 11, 2011 at 4:07 PM, Warner Losh <imp@bsdimp.com> 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 <das@freebsd.org> 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. (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. >>> >>> 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. >> >> 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. > > Loading isn't the problem. The timeouts that you are waiting for are part of the probe/attach sequence. And 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, matthewhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTikCg_yOXEmFASFZQY3xOuT9o5%2Bcdw>