userland boot time

Carsten Haitzler (The Rasterman) raster at
Mon Jan 21 15:58:03 CET 2008

On Mon, 21 Jan 2008 10:46:17 -0300 Werner Almesberger <werner at>

> Carsten Haitzler wrote:
> > 5. syslog - call me a heretic,
> Naw, I won't :-) syslog seems pretty useless under the best of
> circumstances. Perhaps something that gets the messages from things
> that insist on using the syslog interface and just dumps them on the
> console or rotates them in a 16kB buffer in /tmp would be sufficient.

sound good to me - though for speed here just nuking syslog is very fast -
removes software from our fs too (giving us more room) and speeds things up
with really no fuss :) if someone can make a really good case to need it...
then sure - but i am doubtful of that.

last time i did fast-boot stuff (which ended up with 1.6 seconds for kernel +
userspace all the way to x + opengl apps running) it really was a "build it
from the ground up with no fat in the startup you don't need". the result of
course was amazing :) we were shaving off fractions of a second by hard-coding
ide prove values into the kernel to avoid the ide probe - even skipped bogomips
calc. i modified the x drivers to avoid excess chip resets to speed up lcd
init. if we are getting boot time speedups by doing this - then you know you
dont have fat to trip in the init bits :)

> > 12. xserver-nodm - this is where the rest of the bootup pain begins.
> Unfortunately, this is also the first thing we need in terms of giving
> the user the impression that something is happening. It's not so bad
> if things take a long time, but it's bad if users feel that there's
> no progress.

sure. but even here there are stages - the bit where x comes up and displays a
fixed ppm to keep u amused - and then you watch that sit there for a while
until the windowmanager and god knows what else get their act together. by the
look of things this could also be improved. who need the xdefaults stuff
anymore - for example? :) settings-dameon is a heavy beastie too. it links a
lot of shared libs i seriously doubt it needs to do its core job. it's sucked
in libpng, zlib, freetype, pango. libxfixes, xcurso, randr.... when all it does
is read data form gconf (which is probably what sucks all these in) can set x
properties. removing gconf all it needs is libX11 and libc really. so as part
of this glib fun we get gconv internationalization init stuff (settings-daemon
has no need to worry about translations), a bunch of dbus-launch stuff (not
sure where that came from) that should really have been done as the parent
process to the xsession, not as children to settings-daemon, then running xrdb
AGAIN in addition to the xrdb run by the startup scripts... all of this
shenanigans takes about 15 seconds of wall-clock time.

> By the way, before we get excessive with the boot time: how often do
> we actually expect the full system to boot ? When used as a phone,
> most people would probably try to keep it in suspend when power is
> low and then recharge, before running out of juice completely.
> Low-level system hackers (kernel et al.) should get bored with user
> space startup quickly enough that they'll customize their boot
> process anyway.
> So while long boot time is something that catches your eye during
> development, I'm not so sure it matters all that much in real life.
> - Werner

Carsten Haitzler (The Rasterman) <raster at>

More information about the distro-devel mailing list