This article Reprinted from the network base camp: http://xrss.cn/Info/13420.Html
After the Linux cutting of the embedded application was completed last time, it still takes about 7 s to start Linux. Although barely acceptable, it still did not reach my goal-2 s.
. Moreover, in the actual commercial environment, the requirement for device reliability is "5 9" (99.999%, that is, the OOS time is less than 5 minutes/year), which means that each second of Linux Startup is reduced
The device reset time significantly improves the reliability.
To put it bluntly, how can we optimize the Linux Startup time?
The CELF (the Consumer Electronics Linux Forum) Forum guides us in one direction.
(1) first, tracking and analyzing the Linux Startup Process and generating a detailed startup time report.
The simple and feasible method is to add a timestamp for all kernel information during the startup process through the printktime function, which facilitates summary and analysis. Printktime was first provided by CELF
2.6.11 is formally incorporated into the standard kernel. Therefore, you may directly enable this function in the new kernel version. If your Linux kernel cannot be updated to version 2.6.11 or later for some reason
This, you can refer to the methods provided by CELF to modify or directly download the patches they provide: http://tree.celinuxforum.org/CelfPubWiki/PrintkTimes
You can simply enable the printktime function by adding "time" to the kernel startup parameters. Of course, you can also specify the "Kernel
"Show timing information on" in Hacking"
Printks "to force each start to add a timestamp for kernel information. This method also has another advantage: You can get all the information of the kernel before parsing the startup parameter. Therefore, I select the latter
After completing the preceding configuration, restart Linux and run the following command to output the kernel startup information to the file:
Dmesg-s 131072> ktime
Then, use the script "show_delta" (located in the scripts folder of the Linux Source Code) to convert the output file to the time increment display format:
/Usr/src/linux-x.xx.xx/scripts/show_delta ktime> dtime
In this way, you get a detailed report on Linux Startup time consumption.
(2) then, we will use this report to find out the relatively time-consuming process during startup.
It must be clear that there is no necessary correspondence between the time increment and kernel information in the report. The real time consumption must be analyzed from the kernel source code.
This is not difficult for a friend who is a little familiar with programming, because the time increment is only the time difference between two calls to printk. Generally, some time-consuming tasks are completed during kernel startup,
For example, after you create a hash index or probe hardware device, the result is printed through printk. In this case, the time increment usually reflects the time consumed by the corresponding information process. However, in some cases,
The kernel starts the corresponding process only after the printk output information is called. In the report, the time consumed for the corresponding process of kernel information corresponds to the time increment of the next line. In other cases, the time consumption is two.
A certain period of time between kernel information output, so that the time increment may be completely unable to be reflected through kernel information.
Therefore, in order to accurately determine the real time consumption, we need to analyze it with the kernel source code. When necessary, for example, in the third case above, You have to insert printk printing in the source code to further determine the actual time consumption process.
The Linux kernel startup analysis after my last reduction is as follows:
Total kernel Start Time: 6.188 s
Key time-consuming part:
1) initialization of core components such as 0.652 S-timer, IRQ, cache, And mem pages
2) 0.611 S-kernel and RTC Clock Synchronization
3) 0.328 S-computing calibrating delay (total consumption of 4 CPU cores)
4) 0.144 S-calibration APIC clock
5) 0.312 S-calibration migration cost
6) 3.520 S-Intel e1000 Nic Initialization
Next, we will analyze and resolve the above parts one by one.
(3) Next, perform specific optimization.
CELF has already proposed a complete set of startup optimization solutions for Embedded Linux for consumer electronic products. However, due to different applications, we can only use some of their experiences for reference, analyze and try your own problems.
Key kernel components (timer, IRQ, cache, Mem pages ......) Currently, there are no reliable and feasible optimization solutions for initialization.
For items 2 and 3 in the above analysis results, CELF has a special optimization solution: "rtcnosync" and "presetlpj ".
The former is easier to implement by shielding RTC clock synchronization during startup or putting the process after startup (depending on the requirements of specific applications for clock accuracy, but the kernel needs to be supplemented.
Ding. It seems that CELF's current job is only to remove this process, rather than implementing the aforementioned "delay" to process RTC clock synchronization. For this reason, this optimization is not introduced in my solution for the moment (
After all, the time drift has reached the second level.) continue to pay attention.
The latter skips the actual computation process by forcibly specifying the lpj value in the startup parameter, which is based on the fact that the lpj value does not change without changing the hardware conditions. Therefore, after normal startup, record the "calibrating delay" value in the kernel information, and then you can forcibly specify the lpj value in the following form in the startup parameters:
Lpj = 1, 9600700
4 and 5 in the above analysis results
Both items are part of SMP initialization, so they are not in the scope of CELF research (maybe multi-core MP4 will appear in the future ?......), You must be self-reliant. I have studied the SMP initialization generation.
Code, it is found that "Migration cost" can also be like "calibrating
Delay "uses a preset method to skip the Calibration Time. The method is similar. Add the following to the kernel startup parameters:
Migration_cost = 4000,4000
However, it is troublesome for intel to initialize and optimize Nic drivers. Although it is also open-source, reading hardware drivers is no better than reading General C code, besides, "optimization" modifications based on such superficial understanding
It is also difficult to protect the whole world. Based on Reliability, I finally gave up this path after both attempts failed. In this case, we can use CELF's
In the "parallelrcscripts" solution, the "parallel initialization" idea is to compile the NIC driver into a module and load it in the initialization script in sync with other modules and applications to eliminate
The effect of probe blocking on startup time. Considering that the application initialization may also use the network, and in our actual hardware environment, only eth0 is available for use, we need to initialize the first network port
This is included in the 0.3s computing.
In addition to the Optimization points mentioned above in my solution, CELF also proposes some special optimizations that you may be interested in, such:
Shortidedelays-shorten the IDE test duration (my application scenarios do not contain hard disks, so I cannot use them)
Kernelxip-run the kernel directly in ROM or flash (not used considering compatibility)
Idenoprobe-Skip the IDE port of the unconnected device
Optimizercscripts-optimize the linuxrc script in initrd (I used the more concise linuxrc script in busybox)
And other optimization solutions that are still in the hypothetical phase. If you are interested, visit CELF developer wiki to learn more.
(4) optimization results
After the special optimization and redundant reduction of inittab and RCS scripts, the startup time of the entire Linux kernel is reduced from 6.188 s before the optimization to the final
2.016 S. If eth0 Initialization is not included, you only need
1.708 S (eth0 initialization can be parallel to system middleware and some applications), basically achieving the set goal. Works with kexec to greatly reduce the reset time caused by software faults.
To improve product reliability.
If you have any suggestions or questions about Kernel startup time optimization, you are welcome to discuss it with me. :)
This article Reprinted from the network base camp: http://xrss.cn/Info/13420.Html