Ticket #9 (closed defect: fixed)

Opened 12 years ago

Last modified 11 years ago

Boot speed too low (kernel part)

Reported by: laforge@… Owned by: willie_chen@…
Priority: high Milestone:
Component: kernel Version: current svn head
Severity: normal Keywords:
Cc: buglog@…, willie_chen@…, andy@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: PatchReviewResult:
Reproducible:

Description

The boot speed is just too low. We need to import some of the various patches
for boot process speedup.

Change History

comment:1 Changed 12 years ago by laforge@…

  • Status changed from new to assigned
  • dependson set to 8

sometimes, it's mainly the SD card stack that takes so long. we should make
this a module and load it later on.

comment:2 Changed 12 years ago by koen@…

sometimes, it's mainly the SD card stack that takes so long. we should make
this a module and load it later on.

Isn't that a kernel_thread nowadays? I remember needing to set a root_delay
since card detect didn't complete before init started when using root-on-sd.

comment:3 Changed 12 years ago by laforge@…

the sd/mmc related delay was due to a s3cmci bug that has been fixed.

Anyway, we still need to exploit the usual options of boottime optimization
(lpj, no RTC sync, quiet, etc.)

comment:4 Changed 12 years ago by mickey@…

this also relates to bootsplash on/off, supressing boot output, etc. We probably
want to see a bootsplash without messages for the standard boot and have a
dedicated u-boot boot menu item where splash is off and boot messages on.

comment:5 Changed 11 years ago by willie_chen@…

  • Status changed from assigned to new
  • Owner changed from laforge@… to michael@…

comment:6 Changed 11 years ago by willie_chen@…

  • Cc willie_chen@… added

comment:7 Changed 11 years ago by willie_chen@…

  • Owner changed from michael@… to willie_chen@…

comment:8 Changed 11 years ago by andy@…

  • Cc andy@… added

This bug is pretty old, but Mikey's note from March is extra relevant at the
moment -- a fair amount of the boot action is just watching JFFS2 spew the
same diagnostic line which is "usually harmless" for a long time. Maybe a
large part of this time is just printing and scrolling the diagnostic, so we
will shortly try the kernel with "quiet" and time it both ways.

comment:9 Changed 11 years ago by andy@…

The time from booting to being able to do something with the device is currently
~210s here at 200MHz CPU on a GTA-02 A4 board, 73s (34%) of that is spent
sitting there mounting the rootfs at the moment (quiet doesn't significantly
help with this, it's actually doing something inbetween the message spew).

By running the CPU at 400MHz during boot, we shrink the time by a whole minute
to ~150s, rootfs mount taking 56s (37%). So we can make a major (~30%)
difference by leaving U-Boot at 400MHz and implementing cpufreq to crank it down
automatically after boot is completed.

The next biggest prize can be had from attacking the rootfs mount time, either
by chopping the rootfs into two and mounting the bulk of it in the background
while the initscripts run from a smaller "early rootfs" partition, and/or by
trying to optimize the NAND read code.

comment:10 Changed 11 years ago by andy

  • Status changed from new to closed
  • Resolution set to fixed

Kernel part of booting is not abnormally slow now jffs2 summary is used. Booting from SD card, the kernel comes into a shell prompt with init=/bin/sh in ~5s with Wifi set up, this is no longer the source of the remaining boot slowness.

Note: See TracTickets for help on using tickets.