Fixing interactive response in 2.6

While the performance improvements in the 2.6 kernel have impressed and pleased many users, there has been a constant level of complaining about the scheduler. In particular, many users are unhappy with the interactive feel of the 2.6 kernel; reports of jerky response and skipping audio are common. Some have gone as far as to compare the 2.6-test scheduler with the 2.4 virtual memory subsystem at the same point in the development cycle. There is some concern that scheduling could be one of the (few) embarrassments in the upcoming 2.6.0 release. Those worries are probably overdone, but the point is that 2.6.0-test scheduling still needs some work.

The good news is that said work is being done. Con Kolivas has been posting a set of interactivity patches for about a month now. Those wanting to try them out can find them in a recent -mm kernel; patches against the Linus kernels can be found on Con's web site. His most recent patch is 011int.

Con's work follows a familiar theme: improve interactive performance by giving a priority boost to interactive processes. All you have to do is figure out which processes are the interactive ones. Of course, that is rather easier said than done. Con's interactivity patches have been through several iterations in an attempt to find the best way to identify interactive processes and the proper amount of bonus to give them. This patch series may be converging on a result; several testers have reported good results.

The core idea (already part of the 2.6.0-test scheduler) is that an interactive process is one which sleeps much of the time. With Con's patches, any process which sleeps for at least one clock tick gets a priority bonus when it wakes up; processes which have done enough sleeping recently to be explicitly marked as "interactive" get a bigger bonus than others. Processes which run without sleeping for their entire time slice lose a point. In this way, CPU-hog processes sink to the lowest priorities, while a process reading from a terminal (or an audio stream) will get quick access to the processor. Additionally, processes which have maxed out their sleep bonus and are seen as truly interactive can hang out in the run queue for a while even after their time slice expires.

Life is not always so simple, however. Early versions of this patch tended to make life hard for newborn processes; it took them quite a while to build up enough of an interactivity bonus to be able to respond quickly on a loaded system. So things had to be tweaked to let new processes find their natural level quickly. There is also the issue of processes that sleep for a long time, then wake up to do some serious cranking. So processes that sleep for longer than one second lose their interactivity bonus, and end up at an "idle" level just below the interactive level. Work has also been required to balance priorities properly when an interactive process forks.

More recently, Ingo Molnar has also started looking at the interactivity problem; his sched-2.6.0-test1-G6 patch takes a different approach. Ingo starts by changing the scheduler to use nanosecond resolution in its timekeeping; his claim is that, by working with high-resolution time, audio skipping problems can be fixed. Then, the patch splits up time slices so that processes running at the same priority switch off with each other much more often, ensuring that none of them have to wait too long before getting some processor time. Finally, Ingo's patch extends the sleep bonus to include time that the process sits in the run queue, but does not actually get into the processor.

The two sets of patches are mostly orthogonal to each other; while it remains hard to apply both Con's and Ingo's patches to a single system, the two really are addressing different issues. Recent versions of Con's patches, however, also include some of Ingo's work (almost everything except the nanosecond resolution). In the end, code from both patches is likely to find its way into the kernel.

As a postscript, it's worth taking a look at this post from Daniel Phillips, where he states that the wrong approach is being taken for the audio skipping problem. Audio playback, says Daniel, is not an interactive task - it is a realtime task. What is really needed for the audio case is a bounded-latency soft realtime scheduler, not an endless series of interactive scheduler tweaks.

---

(Log in to post comments)