[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora 10 - Boot Analysis

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 redhat com> wrote:


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

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,

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."


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]