[RFC] shipping kernels with default modules?

[Warner Losh]

On Jun 11, 2011, at 6:00 PM, mdf at FreeBSD.org wrote:

> On Sat, Jun 11, 2011 at 4:07 PM, Warner Losh <imp at bsdimp.com> wrote:
>> 
>> On Jun 11, 2011, at 2:43 PM, David Schultz wrote:
>> 
>>> On Sat, Jun 11, 2011, mdf at freebsd.org wrote:
>>>> On Sat, Jun 11, 2011 at 10:18 AM, David Schultz <das at 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.

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