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
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
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.
to post comments)