부팅시간 줄이기 - BootupTimeReductionHowto

이걸 찾으려던게 아닌데, 예전에 한번 읽었던 글이다...
다시 찾으려해도 그렇게 숨어 있더니....

어쨋든.... 예전에 이 글을 참고하여 부팅 시간이 절반 정도로 줄었던 기억이 나네...ㅋㅋㅋ..
 
http://tree.celinuxforum.org/CelfPubWiki/BootupTimeReductionHowto
=====================================================================================
BootupTimeReductionHowto

The items on this page constitute a list of existing techniques for reducing bootup times for embedded systems. Some of these items may also be applicable to desktop or enterprise systems, but that is not the focus.

For each individual item below, a separate page should exist. If it doesn't already exist, a new page should be created using the HowtoTemplate. Links listed in red below are pages that are not created yet. To sign up for a task related to this HOWTO, please see the BootupTimeHowtoTaskList.

---

Table Of Contents:

차례

1. Introduction
   1. Bootup Phases
   2. Main Technique Types
2. Bootup Time Reduction Technique Outline
   1. Firmware Phase
   2. Kernel Phase
   3. User Space Phase
   4. General Reduction Techniques
3. Table of Reduction Techniques
4. Potential Techniques

---

Introduction

Bootup Phases

This document divides the bootup process into 3 main phases:

• Firmware initialization phase
• Kernel initialization phase
• User Space initialization phase

User Space usually consists of a few distinct phases also:

• Initialization scripts (RC scripts, for desktop systems)
  • This is where most daemons and services are loaded.
• Graphics system initialization
• Graphical environment start
• Application initialization

Main Technique Types

Techniques presented here can be organized according to the way they try to achieve their effect. The technique can consist of 1) speeding up the activity 2) doing the activity in parallel with other initialization tasks, 3) doing the activity later (possibly after booting is completed), and 4) avoiding doing the activity at all.

In summary, each technique describes how to take an existing bootup activity and do one of:

• Do it faster
• Do it in parallel
• Do it later
• Don't do it at all

Some techniques will consist of multiple methods (such as both speeding up and doing it in parallel).

Bootup Time Reduction Technique Outline

Following is an outline of different bootup time reduction techniques, organized by the boot phase where they are applied.

Firmware Phase

Here ase some techniques for speeding up the Firmware phase of the boot sequence:

• KernelXIP - Kernel Execute-In-Place

• SkipFirmware - Disable firmware features to eliminate diagnostics, memory counts, etc.

• ParallelHDSpinUp - Parallelize Hard Disk spinup with Kernel load

• DmaCopyOfKernelOnStartup - Use DMA to copy kernel from flash to RAM

Kernel Phase

The following are techniques used to speed up the initialization of the kernel:

• DisableConsole - Turn off serial console output during boot

• PresetLPJ - Use pre-set loops_per_jiffy (avoid calibrate_delay())

• PreconfigurePCI - Preconfigure some PCI bus slots

• IDENoProbe - Don't probe some IDE devices -

• NoProbeMissingDevices - Disable probes for non-existent devices (including keyboards, etc.)

• SmallKernelConfig - Use smallest kernel configuration possible

• ReduceDriverBusyWaits - Shorten device probes by reducing the amount of time the driver busywaits

  • A special case of this is ShortIDEDelays, with IDE driver delays

• ThreadedInit - Perform threaded initialization - replace driver busywaits with yields

  • A special case of this is IDEPreempt, with IDE driver busywaits

• LoadDriversLater - Use modules where possible to move driver initialization later in the boot sequence

User Space Phase

The following are techniques for reducing the bootup time for user-space programs:

• ApplicationXIP - Execute-In-Place for applications and librarys

• ReduceRCScripts - Eliminate unneeded RC scripts

• CustomInitProgram - Use a custom initialization program

  • (This is a special case of eliminating unneeded RC scripts)

• OptimizeRCScripts - Optimize RC script execution

• ParallelRCScripts - Execute RC scripts in parallel, instead of in sequence

• PreLinking - Avoid overhead of runtime link fixups during first program/library load

• ReduceFlashWrites - Reduce writes to flash

• DisableLoggingTurn - off logging to stable storage

• FasterFileSystem - Use faster file system

• RamdiskDuringBoot - Use RAMDISK during boot

• SegmentedFileSystem - Use a segmented file system to avoid interference between reads and writes

General Reduction Techniques

Some reduction techniques don't apply to a specific boot phase, but are general methods to reduce bootup time. These are listed here.

• SmallerPrograms - Use smaller kernel and programs for faster load times

• FasterMemory - Use faster system memory to increase load and initialization performance

Table of Reduction Techniques

The following table summarizes the various techniques listed in this document.

[I'm not sure if the table should replace the information listed in the outline above. I think the table is easier to read. - Tim Bird]

Technique	Boot Phase	Description	Observed reduction	Notes
KernelXIP	Firmware	Kernel Execute-In-Place - avoids kernel copy and decompression time	250 ms	causes runtime performance loss
SkipFirmware	Firmware	Skip firmware probing features, like memory check, bus probing, and device detection, etc.	??	Linux re-probes busses and devices anyway, so this is usually waste of time
ParallelHDSpinUp	Firwmare	Start hard drive spin up before loading kernel	??	Not possible if the kernel is loaded from hard drive.
DmaCopyOfKernelOnStartup	Firmware	Use DMA to copy kernel from flash to RAM	180 ms	.
PresetLPJ	Kernel	Use a hardcoded loops_per_jiffy value to avoid cost of calibration.	250 ms	.
NoProbeMissingDevices	Kernel	Avoid probing for non-existent keyboards and other devices	??	.
SmallKernelConfig	Kernel	Reduce kernel size and length of code paths, thereby reducing execution overhead	??	.
DisableConsole	Kernel	Turn off output to serial console during boot	250 ms	.
PreconfigurePCI	Kernel	Preconfigure PCI bus slots on kernel command line	??	Is this even possible?
LoadDriversLater	Drivers	Move drivers to modules and load them later in boot sequence.)	??	Only works for drivers that can be loaded as modules late in the boot cycle.
IDENoProbe	Drivers	Use "noprobe" on kernel command line for IDE driver	3 sec.	Depends on hardware present
ReduceDriverBusyWaits	Drivers	Reduce the length of driver busy waits	??	.
ShortIDEDelays	Drivers	Reduce length of IDE initialization delays	5 sec.	May be dangerous, depends on hardware
ThreadedInit	Drivers	Replace busywaits in drivers with yields	??	Only adds value if driver can be parallelized with some other init activity.
IDEPreempt	Drivers	Replace busywaits in IDE drivers with yields	250 ms (decreased non-preemptibility)	Already fixed in 2.6
ReduceRCScripts	RC scripts	Eliminate unneeded init scripts	3 sec.	Depends on required scripts
ParallelRCScripts	RC scripts	Start init scripts in parallel	??	.
DeferRCScripts	RC scripts	Defer some init scripts to later in boot cycle	??	.
OptimizeRCScripts	RC scripts	Use busybox, smaller shell, builtins, adjusted scripts	3 sec.	Depends on required scripts
CustomInitProgram	RC scripts	Use custom initialization program (eliminating RC scripts altogether)	10 sec.	requires long-term maintenance of the program
ApplicationXIP	User Space	Use Execute-In-Place for applications and libraries.	??	Requires uncompressed file system. Application performance may be reduced.
SegmentedFileSystem	User Space	Keep read-only data separate from writable data in flash storage	??	.
ReduceFlashWrites	User Space	Avoid writes to flash memory	??	.
RamdiskDuringBoot	User Space	Keep writable files in RAM, and write them to flash after boot	??	.
SmallerPrograms	User Space	Use smallest programs and configurations possible	??	Reduces program load time. It may increase cache hits.
FasterMemory	[General]	Use faster memory	??	.	.

Potential Techniques

Here is a list of potential techniques that have not been tried yet, to our knowledge:

• Use different, faster, firmware
• Cache results of find and grep during RC scripts
• Partial XIP (this is a current project of the WG)