[Repost]Boot Time

Boot Time

S: “Boot Time”

/***************************************************

reference: http://elinux.org/Boot_Time

Boot Time

Contents

 [hide] 1 Introduction

2 Technology/Project Pages 2.1 Measuring Boot-up Time

2.2 Technologies and Techniques for Reducing Boot Time 2.2.1Bootloader speedups

2.2.2 Kernel speedups 2.2.2.1 File System issues

 

2.2.3 User-space and application speedups

2.2.4 Suspend related improvements

2.2.5 Miscellaneous topics

2.2.6 Uninvestigated speedups

 

 

3 Articles and Presentations 3.1 Case Studies

 

4 Additional Projects/Mailing Lists/Resources 4.1Replacements for SysV 'init' 4.1.1 busybox init

4.1.2 upstart

4.1.3 Android init

4.1.4 systemd

 

4.2 Kexec

4.3 Splash Screen projects

4.4 Others 4.4.1 Apparently obsolete or abandoned material

 

 

5 Companies, individuals or projects working on fast booting

6 Boot time check list

 

Introduction

 

Boot Time includes topics such as measurement, analysis,human factors, initialization techniques, and reduction techniques. The timethat a product takes to boot directly impacts the first perception an end userhas of the product. Regardless of how attractive or well designed a consumerelectronic device is, the time required to move the device from off to aninteractive, usable state is critical to obtaining a positive end userexperience. Turning on a device is Use Case #1.

 

Booting up a device involves numerous steps and sequences ofevents. In order to use consistent terminology, the Bootup Time Working Groupof the CE Linux Forum came up with a list of terms and their widely accepteddefinitions for this functionality area. See the following page for theseterms:

Boot-up Time Definition Of Terms

 

Technology/Project Pages

 

The following are individual pages with information aboutvarious technologies relevant to improving Boot Time for Linux. Some of thesedescribe local patches available on this site. Others point to projects orpatches maintained elsewhere.

 

Measuring Boot-up Time

Printk Times - simple system for showing timing informationfor each printk.

Kernel Function Trace - system for reporting functiontimings in the kernel.

Linux Trace Toolkit - system for reporting timing data forcertain kernel and process events.

Oprofile - system-wide profiler for Linux.

Bootchart - a tool for performance analysis and visualizationof the Linux boot process. Resource utilization and process information arecollected during the user-space portion of the boot process and are laterrendered in a PNG, SVG or EPS encoded chart.

Bootprobe - a set of System Tap scripts for analyzing systembootup.

 and, let us notforget: "cat /proc/uptime"

 grabserial - a niceutility from Tim Bird to log and timestamp console output

process trace - a simple patch from Tim Bird to log exec,fork and exit system calls.

ptx_ts - Pengutronix' TimeStamper: A small filter prependingtimestamps to STDOUT; a bit similar to grabserial but not limited to serialports

Initcall Debug - a kernel command line option to show timetaken for initcalls.

 See also: KernelInstrumentation which lists some known kernel instrumentation tools. These areof interest for measuring kernel startup time.

 

Technologies and Techniques for Reducing Boot Time

 

Bootloader speedups

Kernel XIP - Allow kernel to be executed in-place in ROM orFLASH.

DMA Copy Of Kernel On Startup - Copy kernel from Flash toRAM using DMA

Uncompressed kernel - An uncompressed kernel might bootfaster

Fast Kernel Decompression

 

Kernel speedups

Disable Console - Avoid overhead of console output duringsystem startup.

Disable bug and printk - Avoid the overhead of bug andprintk. Disadvantage is that you lose a lot of info.

RTC No Sync - Avoid delay to synchronize system time withRTC clock edge on startup.

Short IDE Delays - Reduce duration of IDE startup delays(this is effective but possibly dangerous).

Hardcode kernel module info - Reduce the overhead of loadinga module, by hardcoding some information used for loading the relocationinformation

IDE No Probe - Force kernel to observe theide=noprobe option.

Preset LPJ - Allow the use of a preset loops_per_jiffyvalue.

Asynchronous function calls - Allow probing or otherfunctions to proceed in parallel, to overlap time-consuming boot-up activities.Threaded Device Probing - Allow drivers to probe devices in parallel. (notmainlined, now deprecated?)

 

Reordering of driver initialization - Allow driver busprobing to start as soon as possible.

Deferred Initcalls - defer non-essential moduleinitialization routines to after primary boot

NAND ECC improvement - The pre 2.6.28 nand_ecc.c has roomfor improvement. You can find an improved version in the mtd git athttp://git.infradead.org/mtd-2.6.git?a=blob_plain;f=drivers/mtd/nand/nand_ecc.c;hb=HEAD.Documentation for this is inhttp://git.infradead.org/mtd-2.6.git?a=blob_plain;f=Documentation/mtd/nand_ecc.txt;hb=HEAD.This is only interesting if your system uses software ECC correction.

Check what kernel memory allocator you use. Slob or slubmight be better than slab (which is the default in older kernels)

If your system does not need it, you can remove SYSFS andeven PROCFS from the kernel. In one test removing sysfs saved 20 ms.

Carefully investigate all kernel configuration options onwhether they are applicable or not. Even if you select an option that is notused in the end, it contributes to the kernel size and therefore to the kernelload time (assuming you are not doing kernel XIP). Often this will require sometrial and measure! E.g. selecting CONFIG_CC_OPTIMIZE_FOR_SIZE (found undergeneral setup) gave in one case a boot improvement of 20 ms. Not dramatic, butwhen reducing boot time every penny counts!

Moving to a different compiler version might lead to shorterand/or faster code. Most often newer compilers produce better code. You mightalso want to play with compiler options to see what works best.

 If you use initramfsin your kernel and a compressed kernel it is better to have an uncompressedinitramfs image. This is to avoid having to uncompress data twice. A patch forthis has been submitted to LKML. See http://lkml.org/lkml/2008/11/22/112

 

File System issues

 

Different file systems have different initialization(mounting) times, for the same data sets. This is a function of whethermeta-data must be read from storage into RAM or not, and what algorithms areused during the mount procedure.

Filesystem Information - has information about boot-up timesof various file systems

File Systems - has information on various file systems thatare interesting for embedded systems. Also includes some improvementsuggestions.

Avoid Initramfs - explains on why initramfs should beavoided if you want to minimize boot time

 Split partitions. Ifmounting a file system takes long, you can consider splitting that filesystemin two parts, one with the info that is needed during or immediately afterboot, and one which can be mounted later on.

Ramdisks demasked - explains why using a ram disk generallyresults in a longer boot time, not a shorter one.

 

User-space and application speedups

Optimize RC Scripts - Reduce overhead of running RC scripts

Parallel RC Scripts - Run RC scripts in parallel instead ofsequentially

Application XIP - Allow programs and libraries to beexecuted in-place in ROM or FLASH

Pre Linking - Avoid cost of runtime linking on first programload

 Statically linkapplications. This avoids the costs of runtime linking. Useful if you have onlya few applications. In that case it could also reduce the size of your image asno dynamic libraries are needed

 GNU_HASH: ~ 50% speedimprovement in dynamic linking  Seehttp://sourceware.org/ml/binutils/2006-06/msg00418.html

 

Application Init Optimizations - Improvements in programload and init time via:  use of mmap vs.read

 control over pagemapping characteristics.

 

Include modules in kernel image - Avoid extra overhead ofmodule loading by adding the modules to the kernel image

 Speed up moduleloading - Use Alessio Igor Bogani's kernel patches to improve module loadingtime by "Speed up the symbols' resolution process" (Patch 1, Patch 2,Patch 3, Patch 4, Patch 5).

 Avoid udev, it takesquite some time to populate the /dev directory. In an embedded system it isoften known what devices are present and in any case you know what drivers areavailable, so you know what device entries might be needed in /dev. Theseshould be created statically, not dynamically. mknod is your friend, udev isyour enemy.

 If you still likeudev and also like fast boot-up's, you might go this way: start your systemwith udev enabled and make kind of a backup of the created device nodes. Now,modify your init script like this: instead running udev, copy the device nodesthat you just made a backup of into the device tree. Now, install thehotplug-daemon like you always do. That trick avoids the device node creationat startup but stills lets your system create device nodes later on.

 If your device has anetwork connection, preferably use static IP addresses. Getting an address froma DHCP server takes additional time and has extra overhead associated with it.

 Moving to a differentcompiler version might lead to shorter and/or faster code. Most often newercompilers produce better code. You might also want to play with compileroptions to see what works best.

 If possible move fromglibc to uClibc. This leads to smaller executables and hence to faster loadtimes.

 library optimisertool: http://libraryopt.sourceforge.net/

 This will allow youto create an optimised library. As unneeded functions are removed this shouldlead to a performance gain. Normally there will be library pages which containunused code (adjacent to code that is used). After optimizing the library thisdoes not occur any more, so less pages are needed and hence less page loads, sosome time can be saved.

 Function reordering:http://www.celinux.org/elc08_presentations/DDLink%20FunctionReorder%2008%2004.pdf

 This is a techniqueto rearrange the functions within an executable so they appear in the orderthey are needed. This improves the load time of the application as allinitialization code is grouped into a set of pages, instead of being scatteredover a number of pages.

 

Suspend related improvements

 

Another approach to improve boot time is to use a suspendrelated mechanism. Two approaches are known.

 Using the standardhibernate/resume approach. This is what has been demonstrated by Chan Ju, Park,from Samsung. See sheet 23 and onwards from this PPT and section 2.7 of thispaper.

 Issue with thisapproach is that flash write is much slower than flash read, so the actualcreation of the hibernate image might take quite a while.

 Implementing snapshotboot. This is done by Hiroki Kaminaga from Sony and is described at snapshotboot for ARM and http://elinux.org/upload/3/37/Snapshot-boot-final.pdf

This is similar to hibernate and resume, but the hibernatefile is retained and used upon every boot. Disadvantage is that no writablepartitions should be mounted at the time of making the snapshot. Otherwiseinconsistencies will occur if a partition is modified, while applications inthe hibernate file might have information in the snapshot related to theunmodified partition.

 

Miscellaneous topics

 

About Compression discusses the effects of compression onboot time. This can affect both the kernel boot time as well as user-spacestartup.

 

Uninvestigated speedups

 

This section is a holding pen for ideas for improvement thatare not implemented yet but that could result in a boot time gain. Please leavea note here if you are working on one of these items to avoid duplicate work.

Prepopulated buffer cache - As initramfs performs anadditional copy of the data the idea is to have a prepopulated buffer cache. Asimplistic scenario would allow dumping the buffer cache when the booting iscompleted and the user applications have initialised. This data then could beused in a subsequent boot to initialize the buffer cache (of course withoutcopying). A possible approach would be to have those data to reside into thekernel image and use them directly. Alternately they could be loadedseparately.

 Unfortunately myknowledge of the internals in this section is not yet good enough to do a trialimplementation.

 Caveats:  is it possible to have the buffer cache splitinto two different parts, one which is statically allocated, one which isdynamically allocated?

 the pages in theprepopulated buffer cache probably cannot be discarded, so they should bepinned

 apart from the buffercache data itself also some other variables might need restoring

 a similar approachcould also be used for the cached file data.

 

Dedicated fs - currently a lot of abstraction is done in fsto make a nice abstraction allowing easy addition of new filesystems andcreating a unified view of those filesystem. While this is pretty neat, theabstraction layers also introduce some overhead. A solution could be to createa dedicated fs system, which supports only one (or maybe 2) filesystems, andeliminates the abstraction overhead. This will give some benefit, but thechance of getting this into the mainline is zero.

 

Articles and Presentations

Embedded Linux boot time reduction workshop materials  By Free Electrons

 Presentation on boottime reduction techniques - Practical labs on Atmel SAMA5 hardware.

 

 "Boot TimeOptimizations" - (Slides | Video) Alexandre Belloni has presented at ELC Europe on Nov 6, 2012

Main link at Free-Electrons

 

 "The RightApproach to Boot Time Reduction" - (Slides | YouTube Video)  Andrew Murray has presented at ELC Europe onOctober 28, 2010 (Free Electrons video here)

 This included a <1 second QT cold Linux boot case study for an SH7724 with some additionalinformation about 'function re-ordering' in user-space

 Similar slides with< 1 second case study for OMAP3530EVM can be found here

 

 "One SecondLinux Boot Demonstration (new version)" (Youtube video by MontaVista)

 "Tools andTechniques for Reducing Bootup Time" (PPT | ODP | PDF | video)  Tim Bird has presented at ELC Europe, onNovember 7, 2008, his latest collection of tips and tricks for reducing bootuptime

Tims Fastboot Tools has online materials in support of thispresentation

 

Christopher Hallinan has done a presentation at theMontaVista Vision conference 2008 on the topic of reducing boot time. Slidesavailable here

Optimizing Linker Load Times (introducing various kinds of bootuptime reduction, prelinking, etc.)

 

Benchmarking boot latency on x86  By Gilad Ben-Yossef, July 2008

 A tutorial on usingTSC register and the kernel PRINTK_TIMES feature to measure x86 system boottime, including BIOS, bootloader, kernel and time to first user program.

 

Fast Booting of Embedded Linux  By HoJoon Park, Electrons and TelecommunicationsResearch Institute (ETRI), Korea, Presented at the CELF 3rd Korean TechnicalJamboree, July 2008

 Explains severaldifferent reduction techniques used for different phases of bootup time

 

Tim Bird's (Sony) survey of boot-up time reduction techniques:Methods to Improve Boot-up Time in Linux - Paper prepared for 2004 Ottawa LinuxSymposium

http://elinux.org/images//8/83/Pdf.gif Reducing Startup Timein Embedded Linux Systems http://elinux.org/images/d/da/Info_circle.png -December 2003 Presentation describing some existing boot-up time reductiontechniques and strategies.

 

Parallelizing Linux Boot on CE Devices PDF of Presentation

Video of Presentation

 

Parallelize Applications for Faster Linux Boot Authored byM. Tim Jones for IBM Developer Works

This article shows you options to increase the speed withwhich Linux boots, including two options for parallelizing the initializationprocess. It also shows you how to visualize graphically the performance of theboot process.

 

Android Boot Time Optimization Authored by Kan-Ru Chen,0xlab

This presentation covers Android boot time measurement andanalysis, the proposed reduction approaches, hibernation-based technologies,and potential Android user-space optimizations.

 

Texas Instruments Embedded Processors Wiki provides theprocedure to optimize Linux/Android boot time: Optimize Linux Boot Time

Android Boot Time Optimization

 

Implement Checkpointing for Android Authored by Kito Chengand Jim Huang, 0xlab

Reasons to Implement Checkpointing for Android Resume tostored state for faster Android boot time

Better product field trial experience due to regularcheckpointing

 

 

 

Case Studies

300 milliseconds from boot loader to shell on ARM with NAND

 Samsungproof-of-acceptability study for digital still camera: see Boot Up TimeReduction PPT and the paper describing this.

Boot Linux from Processor Reset into user space in less than1 Second  In this white paper, Robin Getzdescribes the techniques used to fast-boot a blackfin development board.

 

Booting Linux dm365 Network Camera in 3.2 seconds

Boot of kernel and shell in 0.5 sec (not including u-bootand decompression)

Warp2, Lineo Solutions, 2008. 2.97 sec boot, ARM11, 400MHz

 

Additional Projects/Mailing Lists/Resources

 

Replacements for SysV 'init'

 

The traditional method of starting a Linux system is to use/sbin/init, which processes the file /etc/inittab. This is an init programwhich processes a series of actions for different run-levels and system events(key-combinations and power events).

 

See the init(8) man page and the the inittab(5) man page.

 

busybox init

 

An 'init' applet is often included in BusyBox

 

There used to be (as of 2000) some slight differences in thesupported features of the 'inittab' file between busybox init and full-blowninit. However, I don't know (as of 2010) if that's still the case. (Seehttp://spblinux.de/2.0/doc/init.html for some details)

 

Denys Vlasenko, one of the maintainers of busybox hassuggested a replacement for traditional init for that tool called runsv. Seehttp://busybox.net/~vda/init_vs_runsv.html

 

upstart

 

upstart is the name of a newer Linux desktop systems thatprovides the program /sbin/init, but with different operational semantics.

 Home page:http://upstart.ubuntu.com/

 Wikipedia page:http://en.wikipedia.org/wiki/Upstart

 

Android init

 

Android 'init' is a custom program for booting the Androidsystem.

 

See Android 'init'

 

systemd

 

systemd is a new project (as of May 2010) for startingdaemons and services on a Linux desktop system

 

See http://0pointer.de/blog/projects/systemd.html

 

Kexec

Kexec is a system which allows a system to be rebootedwithout going through BIOS. That is, a Linux kernel can directly boot intoanother Linux kernel, without going through firmware. See the white paper at:kexec.pdf 2004 Kernel Summit presentation: fastboot.pdf

here's another Kexec white paper:Reboot Fast

 

 

Splash Screen projects

Splashy - Technology to put up a splash screen early in theboot sequence. This is user-space code. This seems to be the most current splash screen technology, for majordistributions. A framebuffer driver for the kernel is required.

 

Gentoo Splashscreen - newer technology to put a splashscreen early in the boot sequence  Seethe HOWTO at: HOWTO FBSplash

 

PSplash - PSplash is a userspace graphical boot splashscreen for mainly embedded Linux devices supporting a 16bpp or 32bppframebuffer.

bootsplash.org - put up a splash screen early in bootsequence  This project requires kernelpatches

 This project is nowabandoned, and work is being done on Splashy.

 

 

Others

FSMLabs Fastboot - press release by FSMLabs about fastbooting of their product. Is any of this published?

snapshot boot - a technology uses software resume to boot upthe system quickly.

 

Apparently obsolete or abandoned material

Alert.gif in progress - Boot-up Time Reduction Howto - thisis a project to catalog existing boot-up time reduction techniques.  Was originally intended to be theauthoritative source for bootup time reduction information.

 No one maintains itany more (as of Aug, 2008)

 

Alert.gifno content yet - Boot-up Time Delay Taxonomy - listof delays categorized by boot phase, type and magnitude  Was to be a survey of common bootup delaysfound in embedded devices.

 Was never reallywritten.

 

 

???

Bootup Time Spec

Bootup Time Things To Investigate

Bootup Time Working Group

Bootup Time Task List

Bootup Time Howto Task List

Fast Booting Translation

 

Companies, individuals or projects working on fast booting

 Intel - Arjan van deVen - see http://lwn.net/Articles/299483/

 Tripeaks - seehttp://www.linuxdevices.com/news/NS8282586707.html

 Lineo Solutions - seehttp://www.linuxdevices.com/news/NS5185504436.html

 Monta Vista - seehttp://www.linuxdevices.com/news/NS2560585344.html

 fastboot git tree -see http://lwn.net/Articles/299591/

 MPC Data SwiftBootservices - http://www.swiftboot.com/

 Free Electrons -http://free-electrons.com/services/boot-time/

 

Boot time check list

 

From an August 2009 discussion about boot time on ARMdevices, several hints and advice regarding boot time optimization areavailable. While it may repeat a lot of above, below is a check list extractedfrom this discussion:

 Is CPU's clockswitched to maximum? If the kernel, bootloader or hardware is in charge ofsetting CPU power and speed scaling, then you should check that it boots withthe CPU set at maximum speed instead of slowest.

 Is your hardware(register) timing configuration of your SoC's memory interfaces (e.g. RAM andNOR/NAND timing) optimized? A lot of vendors ship their hardware with "well,it works, optimize later" settings. What you want is "as fast aspossible, but sill stable and reliable" configuration. This might needsome hardware knowledge and has to be customized to the individual memorydevices used.

 Does your boot loaderuses I- and D-Cache? E.g. U-Boot doesn't enable D-Cache by default on ARMdevices, as it needs customized MMU tables to do so.

 Does kernel copy frompermanent storage (e.g. NOR or NAND) to RAM use optimized functions? E.g. DMA,or on ARM at least load/store multiple commands (ldm/stm)?

 If you use U-Boot'suImage, set "verify=no" in U-Boot to avoid checksum verification.

 Optimize size of yourkernel.  You might even try some of theembedded system kernel config options that, for example, eliminate all the printkstrings, reduce data structures, or eliminate unneeded functionality.

 

 How often is kernel(image) data copied? First by boot loader from storage to RAM, then by kernel'suncompressor to it's final destination? Once more? If you use compressed kerneland NOR flash, consider running the uncompressor XIP in NOR flash.

 If you use compressedkernel, check compression algorithm. zlib is slow on decompression, and lzo ismuch faster. So if you implement lzo compression, you'll probably speed thingsup a little as well (check LKML for this). Having no compression at all mayalso be a good thing to try (see next topic).

 Check to useuncompressed kernel (depends on your system configuration). Using anuncompressed kernel on a flash-based system may improve boot time. The reasonis that compressed kernels are faster only when the throughput to thepersistent storage is lower than the decompression throughput, and on typicalembedded systems with DMA the throughput to memory outperforms the CPU-baseddecompression. Of course it depends on a lot of stuff like performance of flashcontroller, kernel storage filesystem performance, DMA controller performance,cache architecture etc. So it's individual per-system. Example: With using anuncompressed kernel (~2.8MB) uncompressing (running the uncompressor XIP in NORflash) took ~0.5s longer than copying 2.8MB from flash to RAM.

 Enable precalculatedloops-per-jiffy

 Enable kernel quietoption

 If you use UBI: UBIis rather slow in attaching MTD devices. Everything is explained at MTD's UBIscalability and UBI fs scalability sections. There is not very much you can doto speed it up but implement UBI2. UBIFS would stay intact. There werediscussions about this and it does not seem to be impossibly difficult to doUBI2 (few ideas).  In a follow-up e-mail,Sascha Hauer wrote:

 

 

"What's interesting about this is that the kernel NANDdriver is much slower

than the one in U-Boot. Looking at it it turned out that thekernel driver uses interrupts to wait for the controller to get ready.Switching this to polling nearly doubles the NAND performance. UBI mounts muchfaster now and this cuts off another few seconds from the boot process  :) "

 Use static devicenodes during boot, and later setup busybox mdev for hotplug.

 If you have networkenabled, there might be some very long timeouts in the network code paths,which appear to be used whether you specify a static address or not. See thedefinitions of CONF_PRE_OPEN and CON_POST_OPEN in net/ipv4/ipconfig.c. Checkipdelay configuration patch.

 Parallelize bootprocess.

 Disable the option"Set system time from RTC on startup and resume", you can use thecommand hwclock -s at the of the init instead of slowing down the kernel.

***************************************************/