Linux 2.6.0 has made significant improvements in the processor scheduler in the 2.6.0 release. Not only are processes scheduled more efficiently, but the scheduler has been redesigned to be more scalable when the number of processes in a machine are increased. In 2.4, the scaling is not as prominent.
An additional benefit to the improvements in the scheduler allows more efficient use of resources, such as forked processes, and with a default kernel configuration, more processes can run on a system than before.
Performance tests were conducted using a test program called hackbench. The tests were run to compare Linux 2.4.18 against the 2.6.0-test9 kernel. The tests were run on four different systems: a single processor system, a system with 2 processors, a system with 4 processors and a system with 8 processors. The system configurations are noted below:
single proc system
dual proc system
4 proc system
8 proc system
The hackbench test is a benchmark for measuring the performance, overhead, and scalability of the Linux scheduler. Created by Rusty Russell, it uses client and server processes grouped to send and receive data in order to simulate the connections established for a chat room. Each client sends a message to each server in the group.
The test creates a group of processes in multiples set by the user (for this report, they were set in multiples of 25). Each client/server pair listens on a socket; the writer writes 100 messages to each socket and the receiver listens on the socket. Therefore in this case, the total number of messages sent are 100 X the number of processes specified. The source for the test file is hackbench.c and is called from a wrapper perl script which is executed in OSDL's Scalable Test Platform. The wrapper script is runit.pl
Each individual test runs a multiple of 25 processes, increments to the next multiple and reruns the benchmark. This continues until a max level, set by the tester, is achieved. For example, the tester may want to exercise the system by running multiples of 25 processes until a maximum of 100 processes is achieved. Thus the benchmark will run tests for 25, 50, 75, and 100 processes before terminating. Each set of processes are executed 5 times, and an average time to complete the exercise is given for each of the sets. The test report has a graph of the averaged times for each of the sets.
The first set of test runs were performed with a maximum value of 200 groups of senders and receivers. The tests were performed on systems with increasing numbers of processors. The graphs below show the average times it took to complete the hackbench test given the specified number of groups of processes at each step.
Comparing 2.4.18 with 2.6.0-test9 shows that 2.4.18 has a parabolic curve, indicating that it logarithmically takes longer to complete the test as the number of groups (senders and receivers) increase. Each sender and receiver is created as a separate process; the process scheduler for 2.4.18 will eventually be unable to manage processes efficiently when the number of processes exceed a certain threshold.
In contrast, the improved 2.6.0-test9 kernel shows a more linear line, indicating that the new process scheduler can manage a larger number of groups created by the hackbench test. The curve also shows that it takes much less time to complete the test than 2.4.18, given the specified number of groups to execute. The end result is that the improvements in the 2.6.0 process scheduler provides greater performance and manages processes more efficiently.
The table below shows the 2.4.18 results for all systems tested in one graph, and the 2.6.0-test9 results for all systems tested in the other graph.
|
|
The results in the 2.4.18 graph show that the performance is nearly indistinguishable on a 2-way and an 8-way system when the number of process groups approach 150. This indicates that the process scheduler in 2.4.18 will not scale as well when larger systems (i.e., greater numbers of processors) are involved. It appears, for this test anyway, the most efficient computer system is composed of four processors.
The 2.6.0-test9 kernel shows a clear distinction between the performance and the number of processors used in a computer system. This implies that there is better scalability as the number of processors increase. The process scheduler (and other components of the kernel) can utilize an increase in the number of processors in a computer system. Therefore, systems that run a high number of processes can benefit by scaling up to a larger system with more processors.
The next set of tests were conducted in order to determine the maximum number of groups that could be executed before the system encountered a resource limitation. No kernel tuning was performed; the tests were executed based upon the default config parameters. The tests were invoked with an increasing value for the maximum number of process groups and left to run until an error message indicated a resource limitation. The error message produced was the following:
groupsfork() (error: Resource temporarily unavailable)
At that time, the tests were aborted and the last complete set was determined. The tables below show the maximum number of process groups that successfully completed the execution of hackbench as the test was executed on systems with increasing numbers of processors.
The table below was run with a maximum of 600 groups. On a single CPU system, both versions of Linux failed after running with 200 groups.
The table below shows the results of a dual processor machine. It shows that under 2.4.18, the maximum number of processes that could be run was 225, but under 2.6.0-test9, the number of processes that could be run were greater; that test was able to execute up to 350 process groups.
The table below shows the results for a 4-way system. Under 2.4.18, the maximum number of processes able to be created with this benchmark was 225, the same as a 2-way system. Under 2.6.0-test9, the number of processes that could be run with this benchmark increased significantly to 525.
The table below shows the results for an 8-way system. Like the 4-way system, the maximum number of process groups under 2.4.18 without running out of resources is 225. Under 2.6.0-test9, the number of process groups that can be run is 425. This is smaller than the 4-way running 2.6.0-test9, but it is still greater than 2.4.18 running on the 8-way.
The result of running the hackbench test on an 8-way in 2.6.0-test9 with a greater value than 425 process groups caused a different error message:
SENDER: write (error: No buffer space available)
The error is called by the hackbench program itself, while trying to write to a buffer in preparation for sending data to a receiver. The error is believed to be caused by a smaller buffer space allocated at startup on the 8-way system. Our particular 8-way has more disks and other peripheral devices than the 4-way, causing more of the resident memory to allocate space to the system kernel. This allowed less remaining buffer space for the hackbench program. It is assumed that the test would run with more process groups if the kernel configuration was tuned. The results may vary depending on the specific hardware on which the test was performed. However, the results show that 2.6.0-test9 on an 8-way is still preferable to 2.4.18.
Linux 2.6.0-test9 is more efficient with regards to scheduling processes, allows for greater scalability if larger systems are used to run a high number of processes, and the efficiency of the scheduler combined with other improvements allow more processes to be executed on systems before resources are exhausted.
Copyright © 2003 Open Source Development Labs, Inc.
Verbatim copying of this document or portions of this document
is permitted in any medium, provided this notice is included.