Fedora 10 - Boot Analysis

[Casey Dahlin]

Harald Hoyer wrote:
> Hans de Goede wrote:
>> Harald Hoyer wrote:
>>> Arjan van de Ven wrote:
>>>> On Mon, 15 Dec 2008 15:47:32 +0100
>>>> Harald Hoyer <harald at redhat.com> wrote:
>>>>
>>>>> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
>>>>>
>>>>> A brief Fedora 10 boot analysis.
>>>>>
>>>>> To reach the 20 Second Startup Feature 
>>>>
>>>> this begs the question, and you knew I as going to ask ;), if Fedora
>>>> wants to reach the 5 second boot that is quite possible on this
>>>> hardware, even without too insane compromises.
>>>> (which translates to something like 2 to 3 seconds on a full sized
>>>> laptop-with-ssd)
>>>>
>>>> If not, I would regret that but it's not something I would have to 
>>>> live
>>>> without; I can get a fast boot myself quite fine. If so, something 
>>>> needs to happen NOW for F11, with a real serious push
>>>> for this. It'll involve quite a few people and quite a few packages
>>>> that need to get things right, but it's not at all impossible nor does
>>>> it require impossible-for-fedora compromises.
>>>>
>>>>
>>>
>>> Push your kernel patches, so we have a kernel fast boot and sreadahead.
>>> Persuade our kernel maintainer to compile more modules in the kernel.
>>>
>>> But, we can't / don't want to drop gnome and most other services, 
>>> you dropped to reach 5 seconds.
>>>
>>
>> I agree with not dropping gnome :) But if we want faster startup we 
>> really should be taking a serious look at trimming startup services.
>>
>> Some ideas:
>> 1) Make more services not start when not needed, for example 
>> bluetooth when there is no bluetooth hardware, etc. We could even 
>> completely stop them from being a service controlled by runlevel and 
>> make them be started from udev instead.
>
> right, directly (and as an upstart event "/sbin/start bluetooth") or 
> via HAL/DeviceKit
>
>>
>> 2) Load some services after gdm is up, for example cron, anacron, at,
>> setroubleshootd
>
> or start them in parallel via upstart
>

parallel boot isn't much of a gain. The only real advantages are when 
there's lots of blocking on hardware other than the disk, and whatever 
is gained from flooding the io scheduler with more requests at once so 
it doesn't have to predict the future to avoid seeks. The later 
advantage disappears once we get readahead right, and by itself it isn't 
better than readahead.

Upstart isn't there to parallelize things. Its there to start things 
reactively as opposed to in response to arbitrary "runlevels."

--CJD