[patch] CFS scheduler, -v12

[Ingo Molnar]

i'm pleased to announce release -v12 of the CFS scheduler patchset.

The CFS patch against v2.6.22-rc1, v2.6.21.1 or v2.6.20.10 can be 
downloaded from the usual place:
  
    http://people.redhat.com/mingo/cfs-scheduler/

-v12 fixes the '3D bug' that caused trivial latencies in 3D games: it 
turns out that the problem was not resulting out of any core quality of 
CFS, it was caused by 3D userspace growing dependent on the current 
inefficiency of the vanilla scheduler's sys_sched_yield() 
implementation, and CFS's "make yield work well" changes broke it.

Even a simple 3D app like glxgears does a sys_sched_yield() for every 
frame it generates (!) on certain 3D cards, which in essence punishes 
any scheduler that implements sys_sched_yield() in a sane manner. This 
interaction of CFS's yield implementation with this user-space bug could 
be the main reason why some testers reported SD to be handling 3D games 
better than CFS. (SD uses a yield implementation similar to the vanilla 
scheduler.)

So i've added a yield workaround to -v12, which makes it work similar to 
how the vanilla scheduler and SD does it. (Xorg has been notified and 
this bug should be fixed there too. This took some time to debug because 
the 3D driver i'm using for testing does not use sys_sched_yield().) The 
workaround is activated by default so -v12 should work 'out of the box'.

Mike Galbraith has fixed a bug related to nice levels - the fix should 
make negative nice levels more potent again.

Changes since -v10:

 - nice level calculation fixes (Mike Galbraith)

 - load-balancing improvements (this should fix the SMP performance 
   problem reported by Michael Gerdau)

 - remove the sched_sleep_history_max tunable.

 - more debugging fields.

 - various cleanups, fixlets and code reorganization

As usual, any sort of feedback, bugreport, fix and suggestion is more 
than welcome,

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/