userland boot time

Andy Green andy at
Mon Jan 21 11:08:42 CET 2008

Hash: SHA1

Somebody in the thread at some point said:

> a) ditch sysvinit and use a monolithic script (think linuxrc). This
> will have the most speed impact, but is a very invasive change
> reducing a whole lot of the flexibility that the audience needs.

In itself it won't do anything, the actual change implicit in that is we
will spawn stuff in the background in parallel and tune when we do that
according to the dependencies.  It is a bit unpleasant because the
dependencies are not even opaque they are implicit in the ordering of
things in the script.

But, we can do this still using /etc/init.d/ scripts and spawn them in
the background in a crafted order.  So it's not out of consideration.

> b) ditch sysvinit and use a better init system. This has a reasonable

In the end, this is the solution that will be acceptable to all the
players, the OE folks will definitely want to end up here in the longer

But I think we must act in the short term with this because the boot
delay has deep impacts in totally other considerations, ie, morale.
When these bad things don't get tackled over long periods, it erodes the
culture that should make bad things unacceptable.  Conversely if we
carry the monsters' heads back to the village when we said we would, no
matter some deviation from an optimum was involved to achieve that, the
culture in the whole village gets a dramatic lift, they understand that
we are in control and not the monsters.

> c) keep sysvinit and just shuffle around runlevels and services. This

The issue here is that the current rcS.d first the rc5.d blocks the sexy
things that live in rc5 (X) until expensive stuff like udev (18s)
completes from rcS.  It means we have to trash the rcS/rc5 distinction,
in fact "runlevels" if we put X starting in the mandatory rcS set.

> * starting the UI at the earliest possible time and


Hey does X need a /dev that is populated by udev?  Don't think so.  It
could have a private dir of fixed device nodes representing what it
actually needed on that machine.  Doesn't have to be in /dev.

> * starting services only when they're necessary.

Yeah -- this is a wider thing about how to block in a hierarchical way
that is solved by a replacement initscript setup.

> This also has positive effects on power consumption.
> Comments?

I think these are good general ideas that will make strong impact, but
we are operating on (albeit reasonable) assumptions that we even
understand where the monsters are hiding.  For example, I was meddling
with this over the weekend, I notices that the JFFS2 garbage collection
daemon can be at ~50% CPU for a while during initscripts.  That kind of
thing make a huge global impact, but you can't guess it.  We need to use
tools to penetrate the mists if possible and make sure we fire at the
actual monsters.

- -Andy
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the distro-devel mailing list