On Monday 16 April 2007, Ingo Molnar wrote:
>this is the second release of the CFS (Completely Fair Scheduler)
>patchset, against v2.6.21-rc7:
>
> http://redhat.com/~mingo/cfs-scheduler/sched-cfs-v2.patch
>
>i'd like to thank everyone for the tremendous amount of feedback and
>testing the v1 patch got - i could hardly keep up with just reading the
>mails! Some of the stuff people addressed i couldnt implement yet, i
>mostly concentrated on bugs, regressions and debuggability.
>
>there's a fair amount of churn:
>
> 15 files changed, 456 insertions(+), 241 deletions(-)
>
>But it's an encouraging sign that there was no crash bug found in v1,
>all the bugs were related to scheduling-behavior details. The code was
>tested on 3 architectures so far: i686, x86_64 and ia64. Most of the
>code size increase in -v2 is due to debugging helpers, they'll be
>removed later. (The new /proc/sched_debug file can be used to see the
>fine details of CFS scheduling.)
>
>Changes since -v1:
>
> - make nice levels less starvable. (reported by Willy Tarreau)
>
> - fixed child-runs first. A /proc/sys/kernel/sched_child_runs_first
> flag can be used to turn it on/off. (This might fix the Kaffeine bug
> reported by S.Çağlar Onur <)
>
> - changed SCHED_FAIR back to SCHED_NORMAL (suggested by Con Kolivas)
>
> - UP build fix. (reported by Gabriel C)
>
> - timer tick micro-optimization (Dmitry Adamushko)
>
> - preemption fix: sched_class->check_preempt_curr method to decide
> whether to preempt after a wakeup (or at a timer tick). (Found via a
> fairness-test-utility written for CFS by Mike Galbraith)
>
> - start forked children with neutral statistics instead of trying to
> inherit them from the parent: Willy Tarreau reported that this
> results in better behavior on extreme workloads, and it also
> simplifies the code quite nicely. Removed sched_exit() and the
> ->task_exit() methods.
>
> - make nice levels independent of the sched_granularity value
>
> - new /proc/sched_debug file listing runqueue details and the rbtree
>
> - new SCH-* fields in /proc/<NR>/status to see scheduling details
>
> - new cpu-hog feature (off by default) and sysctl tunable to set it:
> /proc/sys/kernel/sched_max_hog_history_ns tunable defaults to
> 0 (off). Positive values are meant the maximum 'memory' that the
> scheduler has of CPU hogs.
>
> - various code cleanups
>
> - added more statistics temporarily: sum_exec_runtime,
> sum_wait_runtime.
>
> - added -CFS-v2 to EXTRAVERSION
>
>as usual, any sort of feedback, bugreports, fixes and suggestions are
>more than welcome,
>
> Ingo
This one (v2-rc2) is not a keeper I'm sorry to say, Ingo. v2-rc0 was much
better. Watching amanda run with htop, kmails composer is being subjected to
5 to 10 second pauses, and htop says that gzip -best isn't getting more that
15% of the cpu, and the /amandatapes drive is being written to in a regular
pattern that seems to be the cause of the pauses according to gkrellm, which
also seems to track the size of the writes, and can show anything from 4.3k
to 54 megs as being written in one cycle of its screen update.
Normally hdd will fire up and take it at about 40+M/second steady till its
done when there is a file ready to write even if its a 7GB file. And I can
type right on during the disk i/o. But not now.
In short, I seem to be heavily I/O bound. But when the write to /dev/hdd3 is
done, then gzip -best pops right up to 90% plus cpu and I get my machine
back.
In between file writes I checked the drives speed with hdparm:
root@coyote ~]# hdparm -Tt /dev/hdd
/dev/hdd:
Timing cached reads: 856 MB in 2.01 seconds = 426.15 MB/sec
Timing buffered disk reads: 222 MB in 3.01 seconds = 73.68 MB/sec
That's not too shabby, and obviously dma is active at least for the reading.
gzip -best was running while this was executing. So I think the drive is fine
and the scheduling is whats funkity. Sorry.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
After they got rid of capital punishment, they had to hang twice
as many people as before.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
