Ticket #69 (closed enhancement: wontfix)

Opened 8 years ago

Last modified 4 years ago

Speed up System Initialization

Reported by: mickey@… Owned by:
Priority: normal Milestone: Om2008.10
Component: Distro Version: unspecified
Severity: normal Keywords: Om2008.11
Cc: buglog@… Blocked By:
Blocking: #1845 Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

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

  • runit
  • sysinit-ng
  • upstart

Change History

comment:1 Changed 8 years ago by laforge@…

  • Severity changed from normal to major

comment:2 Changed 8 years ago by jluebbe@…

Harald Welte is working on this.

comment:3 Changed 7 years ago by 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.

comment:4 Changed 7 years ago by 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.

comment:5 Changed 7 years ago by alphaone@…

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

comment:6 Changed 7 years ago by mickey@…

  • Severity changed from major to normal

I agree w/ elrond. Lowering severity.

comment:7 Changed 7 years ago by john_lee@…

  • Owner changed from buglog@… to willie_chen@…

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.

comment:8 Changed 7 years ago by andy@…

  • Owner changed from willie_chen@… to jserv@…

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.

comment:9 Changed 6 years ago by 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).

comment:10 Changed 6 years ago by 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.

comment:11 Changed 6 years ago by 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.

comment:12 Changed 6 years ago by 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.

comment:13 Changed 6 years ago by andy

  • Status changed from new to assigned
  • Owner changed from jserv@… to marek@…

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.

comment:14 Changed 6 years ago by roh

  • Owner changed from marek@… to marek

comment:15 Changed 6 years ago by regina_kim

  • Milestone set to Om2008.9

comment:16 Changed 6 years ago by regina_kim

  • Component changed from sysinit to Distro

comment:17 Changed 6 years ago by zecke

  • Type changed from defect to enhancement

Change to enhancement.

comment:18 Changed 6 years ago by regina_kim

  • Milestone changed from Om2008.9 to Om2008.10

comment:19 Changed 6 years ago by 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/

comment:20 Changed 6 years ago by zecke

  • Blocking 1845 added

(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...)

comment:21 Changed 6 years ago by john_lee

  • Owner changed from marek to olv
  • HasPatchForReview unset

comment:22 Changed 6 years ago by wendy_hung

  • Keywords Om2008.11 added

comment:23 Changed 6 years ago by john_lee

Olv,

Is it okay to put this into testing now?

comment:24 Changed 6 years ago by 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.

comment:25 Changed 6 years ago by 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

comment:26 Changed 6 years ago by olv

  • Owner olv deleted
  1. 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.

comment:27 Changed 6 years ago by 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 :-((

comment:28 Changed 4 years ago by joerg

  • Status changed from assigned to closed
  • Priority changed from high to highest
  • Resolution set to wontfix

comment:29 Changed 4 years ago by joerg

  • Priority changed from highest to normal
Note: See TracTickets for help on using tickets.