CFS scheduler, -v10

i'm pleased to announce release -v10 of the CFS scheduler patchset. (The main goal of CFS is to implement "desktop scheduling" with as
high quality as technically possible.)

The CFS patch against v2.6.21.1 (or against v2.6.20.10) can be downloaded from the usual place:

http://people.redhat.com/mingo/cfs-scheduler/

-v10 got a bit bigger than usual. One reason for that is that i couldnt resist the fine enhancements contributed by Peter Williams and Mike Galbraith. Peter fixed and improved nice level support and SMP load-balancing, while Mike applied his "no compromises" interactivity tuning skills to CFS:

    6 files changed, 247 insertions(+), 110 deletions(-)

the main user-visible change should be that CFS's 3D gaming performance and 'smoothness' should be significantly improved in -v10. This was the main remaining regression reported for -v9 (and for CFS in general).

Changes since -v9:

- complete and finetune the 'smooth load calculation' mechanism (Mike Galbraith)

- generalize and fix up nice level support (Peter Williams)

- fix RT-task load-balancing (Peter Williams)

- added Con Kolivas to the credits section of sched.c, crediting him for the "fair scheduler" idea that CFS is following too.

- made the key calculation 292-years wraparound safe (based on feedback from Esben Nielsen and Linus Torvalds)

- cycle-precise statistics for "top"'s per-task CPU usage fields.

- tune down negative reniced task scheduling granularity (should fix the choppyness reported by Al Boldi)

- re-normalize nice levels close to upstream's values and implement a gentle +10%/-10% "relative nice levels step" when going a nice level up or down. (based on the report from Al Boldi and also based on Peter Williams's feedback)

- improve the /proc/sched_debug output some more

- bugfix for fair-clock update

- other minor fixes

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

Ingo

I finally had time to try bisecting the problem I was having with cfs8 and master Sunday, and was able to eliminate the problem.

I had first done:

clone
branch
checkout
apply
commit
pull

If instead of pulling master into the cfs branch, I rather switch to the master branch and pull the cfs branch into that, it works.

I'll try updating to the current master with v10 to confirm.

For those who want to follow, do:

#!/bin/sh
git clone -l -s -n \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \
2.6.21-cfs-master
cd 2.6.21-cfs-master
git checkout -b git checkout -b cfs v2.6.21
git pull git://people.freedesktop.org/~cloos/cfs-2.6.git
git checkout master
git pull . cfs

The master branch of git://people.freedesktop.org/~cloos/cfs-2.6.git
has 2.6.21 with the sched-cfs-v10-v2.6.21.1.patch. Cf gitweb at:

http://gitweb.freedesktop.org/?p=/users/cloos/cfs-2.6.git

-JimC

James Cloos <[email protected]>         OpenPGP: 1024D/ED7DAEA6

ah! Could you please do a git-diff between the broken and the working tree, to see what got mismerged?

Ingo

Ingo> ah! Could you please do a git-diff between the broken and the working Ingo> tree, to see what got mismerged?

Yes, I can work on that tonight. There will be some noise, but at least both have master == dc87c3985e9b442c60994308a96f887579addc39.

-JimC

James Cloos <[email protected]>         OpenPGP: 1024D/ED7DAEA6

|> git checkout -b git checkout -b cfs v2.6.21

Damn, sorry about the typo. That should of course be:

#!/bin/sh
git clone -l -s -n \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \
2.6.21-cfs-master
cd 2.6.21-cfs-master
git checkout -b cfs v2.6.21
git pull git://people.freedesktop.org/~cloos/cfs-2.6.git
git checkout master
git pull . cfs

-JimC

Ciao Ingo,
care to share some more information regarding how you fixed the "3D gaming performance" issue?

Thanks!

Regards,
Paolo

CFS v10 & SD 0.48 Fedora Core 6 kernels 2.6.20 build 2948 arch x86_64 & i686 are available at http://linux-dev.qc.ec.gc.ca.

- vin

Houston, we have alien artifacts.

Artifact 1:

root@Homer: taskset -c 1 ./thud 5
starting 5 children
running...

root@Homer: taskset -c 1 ./chew

pid 7551, prio   0, interval of 99984800 nsec
pid 7551, prio   0, out for    7 ms, ran for 1690 ms, load  99%
pid 7551, prio   0, out for    2 ms, ran for 1794 ms, load  99%
pid 7551, prio   0, out for    4 ms, ran for 9665 ms, load  99%
pid 7551, prio   0, out for  775 ms, ran for  379 ms, load  32% <== hurt pain ouch!
pid 7551, prio   0, out for   32 ms, ran for    6 ms, load  17%
pid 7551, prio   0, out for   32 ms, ran for    4 ms, load  13%
pid 7551, prio   0, out for   32 ms, ran for    4 ms, load  13%
pid 7551, prio   0, out for   32 ms, ran for    4 ms, load  13%

When thud starts, chew takes a size 14EEE latency hit if bits 1, 2 and 3 are set in sysctl_sched_load_smoothing. Good for burst load, rotten for interactivity if that burst load ain't X. Start a thud 5 without the taskset, and you'll feel the lurch.

Artifact 2:

If both bits 1 and 2 are set, and bit 3 is _not_ set, chew's out drops to ~6ms and run drops to < 1ms. Excessive context switching.

Computing delta_fair with smoothed load in update_curr() fixes some things, but still breaks others. The cost/benefit ratio isn't adding up very favorably. Tinkering.

Values 0x7 and 0xf should be avoided the like plague if your test load includes bursty multiple hogs-from-hell. Values 0x3 and 0xb are merely context switch happy.

-Mike

Well shoot, I take it back. I'm seeing it with 0x1 as well.

pid 6155, prio   0, out for   32 ms, ran for    4 ms, load  13%
pid 6155, prio   0, out for   24 ms, ran for    5 ms, load  19%
pid 6155, prio   0, out for    2 ms, ran for    4 ms, load  69%
pid 6155, prio   0, out for  760 ms, ran for 10031 ms, load  92%
pid 6155, prio   0, out for   32 ms, ran for    4 ms, load  13%
pid 6155, prio   0, out for   32 ms, ran for    4 ms, load  13%