Speed up System Initialization

[mickey@…]

SysVInit is way too slow on the actual device. We should evaluate at least:

• runit
• sysinit-ng
• upstart

[jluebbe@…]

Harald Welte is working on this.

[laforge@…]

I did some work on upstart, but couldn't really finish / get it running.

apart from sysvinit replacement, we should also definitely look at the available
udev alternatives. Is there any work on integrating hotplug2
(http://isteve.bofh.cz/~isteve/hotplug2/) into upstream OE?

If not, we would have to do this in our local tree.

[elrond+bugzilla.openmoko.org@…]

Just my 2cent:

The priority of this bug should be like P4 or so.

The boot works currently quite reliably without bugs. There are really more
important bugs out there, should be fixed before anyone goes to speed up things
that work nicely.

But then, that's my 2ct only.

[alphaone@…]

*** Bug 70 has been marked as a duplicate of this bug. ***

[mickey@…]

I agree w/ elrond. Lowering severity.

[john_lee@…]

This is related to different categories, mainly init structure such as
sysvinit/upstart/runit and scripts/applications running at start time. jserv
and graeme are already working on stuffs related to this.

[andy@…]

This is assigned to Willie, but I don't think we can take this on, it is not
kernel related. I will reassign to jserv (sorry mate) since he is actually
working on it recently. If there is a better person please reassign it
further.

[andy]

This is still pretty bad, for example we run ldconfig every boot "for safety", this adds quite a chunk of time. Upstart would be a big help if it is going to parallelize these guys (especially when some of them like gsmd have sleep()s in them).

[mickeyl]

Actually, a nice handcrafted linuxrc init script with a companion set of prepopulated device nodes would be much simpler and more effective than changing the whole init system. People who need the full sysvinit power could still install it.

[andy]

It won't be effective in removing the serialization for stuff that could be parallelized. But you're right about udev, in DM2 rootfs which is a standard rootfs run through a script to chop it around, I actually did what you suggest here some weeks ago and it is a big boost. I run these chopped about and simplified rootfs' here all day like that.

At this point we just need someone to wade in there and do something, exactly what is not the biggest issue, breaking the deadlock and getting people to fix their packages' init footprint is the issue.

[mickeyl]

Once we stop booting like a desktop system -- launching all services right from the start -- there's hardly anything to parallelize during init.

* Setup device nodes
* mount filesystems
* launch IPC
* jump into X

That's it. All the rest is going to be launched on-demand.

[andy]

Just noting another alternative way from udev is busybox's mdev. We need some kind of dynamic device business to deal with USB hosted devices for example.

I don't think jserv or graeme are looking at this any more... I reassign to Marek because he said he was going to be looking at this recently. Just want to re-iterate doing something -- anything -- about it is better than nothing, don't worry about finding the perfect solution in one hit.

[zecke]

Change to enhancement.

[wich]

There was a demonstration on the Linux Plumbers Conference from Arjan von de Ven and Auke Kok on booting a Linux system in 5 seconds. Maybe you can get some hints from this article.
http://lwn.net/Articles/299483/

[zecke]

(In #1845) @stiell: The gsmd was started way earlier, qpe gets started after X11 gets launched, so Qtopia, E and other processes all try to access our slow flash at once.

What is the relation with #1722. Basicly there is little to fix in this bug. The root is the way we initialize the system, our slow flash. So when #1722 and #69 are solved this should be much faster as well... Trying to change the Qtopia code would not change much, the fix is somewhere else (this does not say that we are not able to speed it up by a second or two but compared to 3 minute boot time...)

[john_lee]

Olv,

Is it okay to put this into testing now?

[wendy_hung]

tested with image below:
kernel:testing-om-gta02-20081210.uImage.bin
rootfs:openmoko-testing-om-gta02.rootfs.jffs2 (20081210)

The boot time now is 50 second from press the power button till you get UI, another 1 minute to get the signal. In total is around 1 min 40~50 seconds.

[john_lee]

In case someone else wants to work on it, I write it here for the record. Another places to look besides boot up scripts will be

1. GSM camping should be started earlier (FSO/Qtopia)
2. boot loader and kernel

[olv]

3. change the theme of enlightenment init screen

Using qi as the bootloader, and taking out enlightenment-init and hal, it is possible to reduce from 50s to 35s.

This is on GTA02 with qtopia. With fso, it is not impossible to make a phone within 1 min since power on.

[andy]

Yes bootloader has already been rewritten into Qi and rejects everything that wastes time in U-Boot. There's possibly another 500ms that can come out of it by playing some difficult tricks but that is it now since it only spends like 3-4s there in total.

I don't think the kernel boot phase can lose much more either, it gets into INIT in a few more seconds. For Qi -> SD Card boot on GTA02 now it's 11s from pressing power button to Ash prompt.

We need to start packaging Qi (Mickey wrote a bb file for it already) into the repos and making sure that the kernel package is compatible (Qi needs the kernel file in /boot/uImage-GTA02.bin rather than just /boot/uImage.bin to allow for multiple kernels in the same rootfs). But I realize with recent events it didn't just get any easier to get things packaged :-((