[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.
Warner
More information about the freebsd-arch
mailing list