Date: Sat, 11 Jun 2011 17:08:45 -0600 From: Warner Losh <imp@bsdimp.com> To: "K. Macy" <kmacy@FreeBSD.ORG> Cc: mdf@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] shipping kernels with default modules? Message-ID: <9349A935-F13D-4265-A59C-C1E9B35F2B73@bsdimp.com> In-Reply-To: <BANLkTino4eMNPQedE1TcxUYqgbuPNfhHKw@mail.gmail.com> References: <BANLkTin2AwKRT7N6HWqBctJcT72_mR=Otg@mail.gmail.com> <20110611171834.GA38142@zim.MIT.EDU> <BANLkTik=z-fb1sDwh0dr4hRWmdhLMWiKdw@mail.gmail.com> <20110611204326.GA51320@zim.MIT.EDU> <BANLkTino4eMNPQedE1TcxUYqgbuPNfhHKw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9349A935-F13D-4265-A59C-C1E9B35F2B73>