Appeasement Scheduling policy

The following SystemTap script is the result of our current research on CPU scheduling.
This SystemTap script changes process priorities based on the requests that they receive from external customers. If you are interested in the underlying theory and how it works, you can read this technical report.
This script has been tested on different Linux distributions including Fedora 12 (kernels 2.6.31 and 2.6.32), RedHat Linux Enterprise 6 Beta, Ubuntu  10.04LTS and 10.10 on both 32 bit and 64 bit versions.
If you are interested in running the script you need to install SystemTap.
You can find SystemTap installation information here.

The appeasement scheduling policy not only improves desktop performance but also improves server application performance under heavy background load.
The following graphs show some of the performance improvements that we get using this scheduling policy.
This figure which is an example of performance improvement for a server application under appeasement scheduling policy, shows the average Mysql transaction times in milliseconds under different (simulated) load conditions.  As we see under the appeasement scheduling policy the average transaction time  is almost constant.





The next figure demonstrates mplayer frame rate change due to the increase in system load.  Again mplayer frame rate is almost constant under this scheduling policy.




For more experimental results please read the technical report.

Dec. 7, 2010

 I have done some scheduling performance tests comparing customer appeasement policy with the recent patch by Mike Galbraith and another similar approach proposed by Lennart Poettering which is known as the alternative to the 200 line patch. These two approaches gather all processes connected to a terminal under a scheduling group and the whole group receives a CPU share equal to all other regular processes in the system. This will prevent the grouped processes from consuming all CPU resources and makes the rest of the system more responsive under certain background loads and in particular parallel kernel compilations.



Although general scheduling latencies for these two approaches are better than our customer appeasement policy, but the scheduling latency for the tasks that have some form of interaction with the user at the time of measurement are smaller under our customer appeasement policy. This is true regardless of the type of background loads and regardless of whether those background processes are associated with any terminals or not.  During my performance tests Firefox was the only interactive process which was playing a video clip from YouTube in one of its tabs. As you see the Firefox thread with the highest CPU time and the Xorg tasks have the lowest scheduling latency under the customer appeasement policy.
This is interesting considering the non-optimal implementation of the appeasement policy and the SystemTap overhead.