A Linux kernel module is code that is linked into the kernel at runtime. The process of inserting a module depends on its size and the number of symbols the kernel must link; however, this time can be reduced to zero if the kernel eschews loading modules and instead has all the modules linked directly into the kernel. For embedded systems with fixed hardware configuration, this makes perfect sense; but for systems that may have changing hardware configurations, adding the drivers directly into the kernel also removes the need to load the correct module at boot or some other time, at the expense of having additional code present that may never be run. The time required to load a module is only one part. Before loading the module, some code is executed to decide whether the module should be loaded in the first place. This logic commonly exists in a shell script. A shell script is very slow, both in terms of raw execution speed and because most shell scripts busily invoke many other programs in order to do their job. The clock is always ticking. If your target must use modules, and boot time is an issue, consider using a C program to contain the logic necessary to figure out what modules need to be loaded. This approach doesn't reduce the amount of time necessary to load a module into the kernel, but it reduces the amount of time necessary to determine what modules should be loaded.
This article describes three tools for determining how long the kernel takes to boot. Some of the tools also measure the time consumed after the kernel has handed control over to the init process. The first is the most simple method, but it doesn't provide much information about why the boot process is slow. The techniques presented give you a better picture of where time is being spent during boot-up so you can focus your attention on the biggest startup delays.
This is a deceptively easy yet effective way to see how fast the system boots: dump the results of /proc/uptime to the console. Making this the first line in your init scripts tells you how long the system has been running and therefore how much time was spent booting. For example:
$ cat /proc/uptime 1.20 0.00
The first column shows the number of seconds the machine has been running, and the second shows the amount of idle time, or the time the CPU was sleeping because it was waiting for I/O or some other external input. Because of the nature of process accounting during the kernel boot process, the second number is zero (or very nearly zero) if executed as the first program. When you print it out after executing initialization scripts, the second number accurately reports the time tasks spend in a sleeping state, waiting for hardware or other input.
This script prefixes output from the serial port with a timestamp so you can see how much time each action takes that has some output via printk. You can then correlate this to a driver and decide if you want to include the driver or delay the startup. Using this code requires that the device produce boot information on a serial port or a USB port acting like a serial port. This is a very easy program to use and makes it simple to find slow spots in the kernel boot process.
Reducing the amount of time necessary to get Linux up and running after the kernel is done booting is much more direct. The kernel mounts a root file system and then runs a program that is responsible for starting all the other processes in the system. In the vast majority of standard Linux systems, like servers and desktop machines, that program is called init, and it runs several other programs to boot the system; this program is designed for flexibility, not expediency. In an embedded system, the primary concern is booting the system to the point that the user can begin using the device as soon as possible. In order to get the fastest booting speeds, the initialization routines skip the flexibility offered by the startup systems on a desktop or server system. The following parts cover proven techniques that reduce the time necessary to get a system up and running as quickly as possible. Unlike the kernel boot process, where effort results in subsecond savings, putting effort into streamlining the boot process when the kernel hands control to the init program can result in a boot process that shrinks by tens of seconds.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Xavier Bartholomew Jamesson at 02022010
1. Break ins
© 2009 ArticleInput.com.