Brief Introduction to the Linux kernel version Stability Test-general Linux technology-Linux programming and kernel information. The following is a detailed description. In the test of Linux kernel version stability, it is necessary to explicitly declare and prove why the version is stable or unstable. However, it has not been proved and confirmed that stress tests within the current system range can test the overall stability of the Linux kernel. This article provides a method to create a Linux stress test within the system range and verify the result. Different Linux developers, users, and release versions use their own methods to test kernel stability. However, the basic information about the tests they decide to run, the Code covered, and the pressure level they reach is not released, which greatly reduces the value of the results.
Using lab machines and tests from the Linux Test Project Test suite, we developed a Test combination based on statistics on the utilization of system resources to provide sufficient pressure for the system. We analyzed this combined test to determine which parts of the Linux kernel are used in the test execution. Then we modified the composite test to increase the percentage of code coverage while maintaining the expected high-intensity system pressure. The final stress test covers enough of the Linux kernel to facilitate stability declaration, and supports data with system usage and kernel code coverage.
The four steps of this combined test method are: Test selection, system resource utilization evaluation, kernel code coverage analysis, and final stress test evaluation.
Select Test
The test selection includes two tests:
-The test should be able to obtain a high level of resource utilization in the main kernel areas such as CPU (s), memory, I/O, and network.
-The test should fully overwrite the kernel code to support the stability statement generated from the results.
If possible, automated or easy-to-Modify tests must be used to support automatic operations. Automatic operations can make the test faster and repeat, and help reduce the risk of human error. Another aspect to consider when selecting an appropriate test is the use of applications that can freely publish results. It is best to choose a test and test suite that firmly supports open source code methods and/or GPL to help ensure the simplicity of the release process.
Evaluate system resource utilization
The combination of the selected tests must put sufficient pressure on system resources. The four main aspects of the Linux kernel can affect the system response and execution time:
-CPU: the time used to process data on the machine's CPU (s.
-Memory: the time when the data is read and written from the real Memory.
-I/O: the time when data is read and written from the disk memory.
-Networking: the time when data is read and written from the network.
The test designer should use the following two well-known open-source Linux Resource monitoring tools to evaluate the resource utilization level. (See references later in this article for links to download these tools .)
-Top: an open-source tool maintained by Albert D. Cahalan. It is included in most Linux releases and can be used for the current 2.4 and 2.6 kernels.
-Sar: Another open source code tool, which is maintained by Sebastien Godard. This tool is also included in most Linux releases and can be used for the current 2.4 and 2.6 kernels.
The evaluation phase of system resource utilization in the method usually requires multiple attempts to obtain a suitable test combination and get the expected level of utilization. Overuse is always a critical issue when determining a test combination. For example, if the selected combination is too limited by I/O, the CPU test result may be poor, and vice versa. This part of the method involves a large number of experiments and errors until all resources reach the expected level.
The top tool can be used to quickly determine which resources (CPU, memory, or I/O) are affected by each test and display in real time how many resources are used. The sar tool collects network utilization statistics over a period of time and records snapshots of all utilization data to one file.
After a combination is selected, the test must run for a long time to accurately evaluate the resource utilization rate. The duration of the test depends on the length of each test. If multiple tests run at the same time, the time must be long enough so that the longest of these tests can be completed. In this evaluation process, sar tools should also be running. In the conclusion of evaluation operation, you should collect and evaluate the utilization levels of all four types of resources.
The following example shows the CPU, memory, and network usage of the sar output:
