This is a scheduler policy rewrite designed to be interactive by design 
without tweaks or tuning and be lean and extensible for all sorts of 
settings. (see previous announcements for more detail).

Patches (including incrementals from previous versions) against 2.6.7 
and 2.6.7-mm2 can be downloaded from:
http://ck.kolivas.org/patches/2.6/

At this point all known bugs that have come up from testers have been 
addressed. For testers of this patch please note that renicing tasks to 
-ve values will not improve the behaviour of games and the like (usually 
it worsens it). Users will be rewarded by judicious use of +nice values 
as nice has profound effects with this scheduler.

Note, for multiuser machines and servers I recommend disabling 
interactive mode:
echo 0 > /proc/sys/kernel/interactive


Changes since v7.3

A very difficult to track (and reproduce) bug was finally sorted out 
where a task that forked repeated cpu bound tasks for just the right 
duration before they stopped would be able to DoS other tasks. Basically 
since every time the parent would go to sleep it would wake up back at 
it's best priority it meant the children would run only for as long as 
needed to stay at that same priority thus hogging all cpu resources. 
This was addressed using the existing infrastructure already in place in 
staircase. It deals with ultra short running tasks by making each next 
wakeup actually continue as though they are still running their first 
timeslice. Thus their priority drops over time in spite of repeated 
wakeups. Great thanks to Pauli Virtanen for his testing and help in 
nailing this.

The other change involves a design issue with the behaviour of the O(1) 
scheduler. If task a is preempted by a higher priority task b, task a 
gets requeued to run after all tasks of the same priority as itself. 
Preempted tasks are now flagged as having that happen and will go ahead 
of other tasks getting to continue where it left off. This tends to 
smooth out the jitter of things like X and audio somewhat, and because 
they may run again if task b runs only briefly it helps preserve cache. 
Thus on preliminary benchmarks I've found a slight improvement in 
throughput under heavy load.

Attached is the patch against 2.6.7.

Regards,
Con