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. >>=20 >> 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. >=20 > 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>