Re: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001release)

[Helge Hafting]

Kyle Moffett wrote:

> On Feb 14, 2005, at 20:17, Lee Revell wrote:
>
> > On Mon, 2005-02-14 at 16:16 -0800, Tim Bird wrote:
> >
> > > Lee Revell wrote:
> > >
> > > > But, I was referring more to things like GDM not being started 
> > > > until all
> > > > the other init scripts are done.  Why not start it first, and let the
> > > > network initialize while the user is logging in?
> > >
> > >
> > > There are a number of techniques used by CE vendors to get fast bootup
> > > time.  Some CE products boot Linux in under 1 second.  Sony's
> > > best Linux boot time in the lab (from power on to user space)
> > > was 148 milliseconds, on an ARM chip (running at 200 MHZ I believe).
> >
> >
> > The reason I marked by response OT is that the time from power on to
> > userspace does not seem to be a big problem.  It's the amount of time
> > from user space to presenting a login prompt that's way too long.  My
> > distro (Debian) runs all the init scripts one at a time, and GDM is the
> > last thing that gets run.  There is just no reason for this.  We should
> > start X and initialize the display and get the login prompt up there
> > ASAP, and let the system acquire the DHCP lease and start sendmail and
> > apache and get the date from the NTP server *in the background while I
> > am logging in*.  It's not rocket science.
>
>
> Such a system needs a drastically different bootup process than currently
> exists, including the ability to specify init-script dependencies.  (Like

The init-script dependencies are specifies already - at least on debian.
Look at the most used runlevel, ls /etc/rc2.d:

S10sysklogd@
S11klogd
S14ppp
S18portmap
S19slapd
S20alsa
S20cupsys
S20dhcp3-server
S20exim
...
The numbers specify ordering constraint, low numbers must start before 
high numbers.
But plenty of scripts have no interdependencies, I have 18 scripts 
numbered S20.
Today they start sequentially anyway, in alphabetical order.  Several of 
them simply
wait for hardware, which could be done in parallel.  So parallel 
execution would be a win.
One could always have a user-settable limit on how much to run in 
parallel, to help
out those low-memory machines. 

> for example user login via GDM (and with our setup, GDM working at all)
> requires that AFS is mounted and NIS is working, which both require the
> network to be available, which requires...  You can see where this is

Yes.  I don't think the X system will start before other things in a 
standard
installation, precisely because it *might* need the network and a bunch 
of other
things to validate the user.  So most of the gain will come from the 
parallel starting
of earlier scripts.
I think one can safely say that the xserver it won't need web, email
or the printer subsystems to get up though, and that could also save 
some time.

> going.  I think eventually we need a better /sbin/init, one that can use
> a traditional legacy /etc/inittab file in addition to a newfangled
> simultaneous boot process with lots of ways to start various kinds of
> services.  Unfortunately such a system will need a _LOT_ of work and
> testing to make sure it doesn't break existing setups.  Oh well, I can
> dream, can't I? :-D

It isn't all that hard.  An init with one change - scripts with the same 
number
runs in parallel instead of sequentially. (And possibly some 
configurable limit
on parallel scripts).  Then the rest of the work lies in an efficient 
and correct numbering of those
scripts.  The paranoid can renumber them so they run in the same
order as they used to.  Most people can use the existing numbering, 
perhaps they
discover an ordering bug or two which is trivially fixed using "mv" to 
renumber scripts.
And the more daring can renumber their scripts for maximum parallelism.

Even with today's system the goal of starting X early is achievable.  If you
know that X doesn't need the network on _your_ machine - renumber it to
start really early.  The modification is easy enough to do. :-)

If it still starts slow, swithc to a light session manager (like xdm) and
a lightweight window manager that doesn't bring in kde or gnome.

Helge Hafting



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/