Before we proceed with the description of the different load balancers, we describe the two benchmarks (Mkbench and Chat) that are used in this study. These two benchmarks will be referenced in the load balancing section.
Mkbench consists of the multiple parallel compilation of the Linux kernel. This has traditionally been a popular benchmark in the Linux community, as it is often seen in development environments. It offers a good mix of I/O and CPU-bound phases especially when a parallel build is used. Parallel builds are issued by using the -j option of the make command. Our measurements of runqueue lengths during such compiles show that the number of runnable threads in the system roughly corresponds to the job size specified by the -j option.
The Chat benchmark, which can be found at https://lbs.sourceforge.net/, simulates chatrooms with multiple users exchanging messages using TCP sockets. The benchmark is based on the Volano Java benchmark, which was used in some of the first reports of scalability limitations with the default SMP scheduler (DSS) of Linux [2]. Each chatroom consists of 20 users with each user broadcasting a variable number of 100 byte messages to every other user in the room. A user is represented by two pairs of threads (one each for send and receive) on the client and server side, resulting in 4 threads per user and 80 threads per room. Each message is sent from the client_send to its server_receive which then broadcasts it to all other client_receive threads in the room. 100 messages sent by each user translate to 20*100*19=38,000 messages being sent and received per room. Each receive is a blocking read and the interleaving of numerous reads and writes causes the scheduler code to be invoked frequently. The characteristic parameters of the Chat benchmark are the number of rooms and the number of messages per user. From a scheduler perspective, the former controls the number of threads created and the latter controls the number of times threads sleep and awaken via blocking reads. At the end of a benchmark run, the client side reports the throughput in number of messages per second. A higher throughput indicates a more efficient kernel scheduler.