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@xxxxxxxxxx> 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
