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
* James Cloos <[email protected]> wrote:
> 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.
ah! Could you please do a git-diff between the broken and the working
tree, to see what got mismerged?
Ingo
|> 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
>>>>> "Ingo" == Ingo Molnar <[email protected]> writes:
>> 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.
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
On 5/7/07, Ingo Molnar <[email protected]> wrote:
>
> 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).
Ciao Ingo,
care to share some more information regarding how you fixed the "3D
gaming performance" issue?
Thanks!
Regards,
Paolo
> -----Message d'origine-----
> De : [email protected]
> [mailto:[email protected]] De la part de Ingo Molnar
> Envoy? : 7 mai 2007 12:34
>
>
> 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(-)
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.
> Ingo
- vin
On Mon, 2007-05-07 at 18:33 +0200, Ingo Molnar wrote:
> - complete and finetune the 'smooth load calculation' mechanism
> (Mike Galbraith)
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
On Tue, 2007-05-08 at 09:51 +0200, Mike Galbraith wrote:
> When thud starts, chew takes a size 14EEE latency hit if bits 1, 2 and 3
> are set in sysctl_sched_load_smoothing.
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%
Ingo Molnar wrote:
>
> 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.)
Thanks! I like this one a lot.
There is one workload that is still handled a bit strange, though. Try
running '# ping 10.1 -A > /dev/null' x3000. Thread creation is great until
it hits a wall around 950, bringing system response to a screaching halt.
Setting sched_load_smoothing from 7/8 to 1, moves the wall to around 2100,
which is great, but where do these walls come from?
Thanks!
--
Al