SDB:Balancing Interactivity with SuSE Linux 9.0

Version: 9.0

SuSE Linux 9.0 -- Balancing Interactivity

Since SuSE Linux 9.0, there are some changes in the default scheduler settings. See the explanation below.

A Linux system has many processes, most of them sleeping and waiting for work. As soon as they get work to do (hardware interrupt, network connection, etc.), they are awakened by the kernel as soon as possible. When you move the mouse, you want the X server to wake up and move the pointer immediately. When the sound card's bufffer runs low, you want xmms (or whatever generates sound for you) to wake up as soon as possible to fill it up again to avoid sound hiccups. When you enter a character into your word processing application, text editor, or shell, you want it to appear immediately.

When just one process needs to run, there is no problem.

When there are several running processes, the kernel normally lets a process run for a certain amount of time (time slice) then interrupts it and gives the CPU to another process. The length of these time slices determines how long the different processes actually get to run. The time slices are relatively short, so the processes seem to run simultaneously (multitasking), even if there is only one CPU.

When a waiting process wakes up in such a situation, the kernel needs to decide whether to interrupt (preempt) the currently running process. This is done based on priorities adjusted according to whether the kernel thinks the process is "interactive". Processes that wait (sleep) most of their time are considered interactive.

As long as there is only one interactive process and not too many processes are running, this works well, regardless of the scheduling frequency. However, the determination of interactiveness can fail, for example, because a process happened had consumed a lot of CPU before. (have some background load, such as compilation, computation, etc., and move solid Windows around for a while on an unaccelerated X server to provoke this: The X server consumes too much CPU and the mouse movement becomes jumpy.)

In such a situation, a process that should be woken up may need to wait until other processes' time slices expire (scheduling latency). The sooner this happens, the lower the scheduling latency and the better the interactive feel.

The scheduling frequency can be tuned on SUSE 9.0 kernels with SCHED_MINTIMESLICE/MAXTIMESLICE settings. When set shorter, the scheduling latencies become smaller, thus the effects of the situations where an interactive process cannot be woken immediately as described above become less visible. To be able to set shorter time slices, use a higher timer frequency than the standard one of HZ=100/s.

The higher scheduling frequency has a cost. The higher timer interrupt frequency needs the time interrupt handler to run more often, every time consuming a few CPU cycles and spoiling part of the CPU cache. (This accounts for ~1% of performance loss when using HZ=1000 instead of 100.)

Using shorter time slices also has a cost: switching from on process to another consumes CPU cycles and also does make the CPU caches less effective. (This accounts for another ~3% of performance loss when using ten times shorter time slices than std.) Thus the higher timer interrupt rate and the shorter scheduling time slices have been made tunable.

The "desktop" boot parameter sets ten times shorter time slices (1-31ms) and ten times higher timer interrupt rate (1000/s) than standard. Omitting it leaves you with the standard settings (10-310ms time slices, 100 time interrupts per second). Alternatively, the timer frequency can be set manually to a multiple (or fraction of) 100 by using HZ= boot parameter. The time slices can be set by SCHED_MIN/MAXTIMESLICE in the kernel sysconfig file. <keyword>kernel,boot.sched,skipped,hz,100,1000,desktop</keyword>