[RFC] shipping kernels with default modules?

Warner Losh imp at bsdimp.com
Sat Jun 11 23:09:31 UTC 2011

On Jun 11, 2011, at 2:49 PM, K. Macy wrote:

>>> 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.
> Although I imagine that many drivers silently benefit from being
> loaded serially, to the best of my knowledge there is nothing
> architecturally requiring this apart from the fact that the scheduler
> isn't started until everything else tied to initialization happens.
> The absence of any sort of preemption was a bit of a thorn in my side
> back when I was working on "xenbus", as the linux implementation
> relies on the use of multiple thread contexts. I don't know how much
> effort to date has been put in to making boot fast.

Right now newbus uses Giant for all its locking.  That's the biggest problem preventing parallel probe/attach.  Also, each and every bus calls probe, then calls attach for each device in sequence.  Fixing that would require changing all the bus drivers.


More information about the freebsd-arch mailing list