Ingo Molnar announced version 20 of his Completely Fair Scheduler patchset, offering further cleanups for the new scheduler code that will be part of the upcoming 2.6.23 kernel, "there have been lots of small regression fixes, speedups, debug enhancements and tidy-ups - many of which can be user-visible." Ingo went on to summarize:
"There are nearly 100 changes - they do add up to a significant total linecount change. There was no crash bug or hang bug found in the CFS code since v19 was released. (in fact the last crash/hang bug in CFS was found and fixed in v7, more than 3 months ago, and even that crash only happened in an uncommon sw-suspend setup, not during normal use. So CFS has turned out to be a pretty robust codebase.) Nevertheless, if you had any problems (performance or behavioral) with v19 it's worth checking v20 out - and if v19 worked great for you it's worth checking out that v20 still works great =B-)"
From: Ingo Molnar [email blocked] To: linux-kernel Subject: [patch] CFS scheduler, -v20, for v2.6.22.5, v2.6.21.7, v2.6.20.16 Date: Thu, 23 Aug 2007 11:43:46 +0200 By popular demand, here is release -v20 of the CFS scheduler. It is a full backport of the latest & greatest v2.6.23-rc3 CFS code to v2.6.22.5, v2.6.21.7 and v2.6.20.16. The patches can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ Changes since -v19: there have been lots of small regression fixes, speedups, debug enhancements and tidy-ups - many of which can be user-visible. See the detailed shortlog below - there are nearly 100 changes - they do add up to a significant total linecount change. There was no crash bug or hang bug found in the CFS code since v19 was released. (in fact the last crash/hang bug in CFS was found and fixed in v7, more than 3 months ago, and even that crash only happened in an uncommon sw-suspend setup, not during normal use. So CFS has turned out to be a pretty robust codebase.) Nevertheless, if you had any problems (performance or behavioral) with v19 it's worth checking v20 out - and if v19 worked great for you it's worth checking out that v20 still works great =B-) Also, the backported CFS scheduler enables people to test suspected scheduler regressions on older codebases too, to filter out the effects of other changes. v20 has been build and boot tested on both 32-bit and 64-bit x86, ontop of all 3 backport kernel bases. As usual, any sort of feedback, bugreport, fix and suggestion is more than welcome! Ingo -------------------> Adrian Bunk (1): sched: make global code static Al Viro (1): take sched_debug.c out of nasal demon territory Alexey Dobriyan (2): Fix leaks on /proc/{*/sched,sched_debug,timer_list,timer_stats} sched: remove binary sysctls from kernel.sched_domain Avi Kivity (1): sched: arch preempt notifier mechanism Ingo Molnar (68): sched: make cpu_clock() not use the rq clock sched: remove cache_hot_time sched: calc_delta_mine(): use fixed limit sched: uninline calc_delta_mine() sched: uninline inc/dec_nr_running() sched: ->task_new cleanup sched: move load-calculation functions sched: add schedstat_set() API sched: use schedstat_set() API sched: reduce debug code sched: batch sleeper bonus sched: reorder update_cpu_load(rq) with the ->task_tick() call sched: uninline rq_clock() sched: schedule() speedup sched: clean up delta_mine sched: delta_exec accounting fix sched: add [__]update_rq_clock(rq) sched: eliminate rq_clock() use sched: remove rq_clock() sched: eliminate __rq_clock() use sched: remove __rq_clock() sched: remove 'now' use from assignments sched: remove the 'u64 now' parameter from print_cfs_rq() sched: remove the 'u64 now' parameter from update_curr() sched: remove the 'u64 now' parameter from update_stats_wait_start() sched: remove the 'u64 now' parameter from update_stats_enqueue() sched: remove the 'u64 now' parameter from __update_stats_wait_end() sched: remove the 'u64 now' parameter from update_stats_wait_end() sched: remove the 'u64 now' parameter from update_stats_curr_start() sched: remove the 'u64 now' parameter from update_stats_dequeue() sched: remove the 'u64 now' parameter from update_stats_curr_end() sched: remove the 'u64 now' parameter from __enqueue_sleeper() sched: remove the 'u64 now' parameter from enqueue_sleeper() sched: remove the 'u64 now' parameter from enqueue_entity() sched: remove the 'u64 now' parameter from dequeue_entity() sched: remove the 'u64 now' parameter from set_next_entity() sched: remove the 'u64 now' parameter from pick_next_entity() sched: remove the 'u64 now' parameter from put_prev_entity() sched: remove the 'u64 now' parameter from update_curr_rt() sched: remove the 'u64 now' parameter from ->enqueue_task() sched: remove the 'u64 now' parameter from ->dequeue_task() sched: remove the 'u64 now' parameter from ->pick_next_task() sched: remove the 'u64 now' parameter from pick_next_task() sched: remove the 'u64 now' parameter from ->put_prev_task() sched: remove the 'u64 now' parameter from ->task_new() sched: remove the 'u64 now' parameter from update_curr_load() sched: remove the 'u64 now' parameter from inc_load() sched: remove the 'u64 now' parameter from dec_load() sched: remove the 'u64 now' parameter from inc_nr_running() sched: remove the 'u64 now' parameter from dec_nr_running() sched: remove the 'u64 now' parameter from enqueue_task() sched: remove the 'u64 now' parameter from dequeue_task() sched: remove the 'u64 now' parameter from deactivate_task() sched: remove the 'u64 now' local variables sched debug: remove the 'u64 now' parameter from print_task()/_rq() sched: move the __update_rq_clock() call to scheduler_tick() sched: remove __update_rq_clock() call from entity_tick() sched: clean up set_curr_task_fair() sched: optimize activate_task() sched: optimize update_rq_clock() calls in the load-balancer sched: make the multiplication table more accurate sched: round a bit better sched: fix update_stats_enqueue() reniced codepath sched: refine negative nice level granularity sched: improve rq-clock overflow logic sched: fix typo in the FAIR_GROUP_SCHED branch sched debug: dont print kernel address in /proc/sched_debug sched: fix sleeper bonus Josh Triplett (2): sched: mark sysrq_sched_debug_show() static sched: mark print_cfs_stats static Nick Piggin (1): sched: debug feature - make the sched-domains tree runtime-tweakable Oleg Nesterov (1): sched: run_rebalance_domains: s/SCHED_IDLE/CPU_IDLE/ Peter Williams (3): sched: tidy up left over smpnice code sched: simplify move_tasks() sched: fix bug in balance_tasks() Randy Dunlap (1): sched: fix kernel-doc warnings Satoru Takeuchi (1): sched: remove unused rq->load_balance_class Ulrich Drepper (1): sched: clean up sched_getaffinity()
From: Ingo Molnar [email blocked] Subject: Re: [patch] CFS scheduler, -v20, for v2.6.22.5, v2.6.21.7, v2.6.20.16 Date: Thu, 23 Aug 2007 12:25:23 +0200 * Ingo Molnar [email blocked] wrote: > By popular demand, here is release -v20 of the CFS scheduler. It is a > full backport of the latest & greatest v2.6.23-rc3 CFS code to > v2.6.22.5, v2.6.21.7 and v2.6.20.16. The patches can be downloaded > from the usual place: update: i missed a small SMP balancing fix so i've updated the patches to -v20.1. Ingo
From: Ingo Molnar [email blocked] To: Linus Torvalds [email blocked] Cc: Andrew Morton [email blocked], linux-kernel@vger.kernel.org Subject: [git pull request] scheduler updates Date: Thu, 23 Aug 2007 18:07:59 +0200 Linus, please pull the latest scheduler git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git It includes six fixes: an s390 task-accounting fix from Christian Borntraeger, sysctl directory permission fixes from Eric W. Biederman, an SMT/MC balancing fix from Suresh Siddha (we under-balanced) and another fix from Suresh for debugging tweak side-effect. Plus there's a sched_clock() quality fix for CPUs that stop the TSC in idle (acked by Len Brown) and a reniced-tasks fixlet. the SMT/MC blancing fix has the highest risk - but since it causes slightly more balancing (instead of less balancing, which is the more risky action) it should be pretty safe. Key workloads still seem fine. Tested on 32-bit and 64-bit x86 and it has passed 200+ make randconfig build tests. Ingo ----------------> Christian Borntraeger (1): sched: accounting regression since rc1 Eric W. Biederman (1): sched: fix sysctl directory permissions Ingo Molnar (2): sched: sched_clock_idle_[sleep|wakeup]_event() sched: tweak the sched_runtime_limit tunable Suresh Siddha (2): sched: fix broken SMT/MC optimizations sched: skip updating rq's next_balance under null SD arch/i386/kernel/tsc.c | 1 drivers/acpi/processor_idle.c | 32 +++++++++++++++---- fs/proc/array.c | 44 +++++++++++++++++---------- include/linux/sched.h | 5 +-- kernel/sched.c | 68 +++++++++++++++++++++++++++++++----------- kernel/sched_debug.c | 3 + 6 files changed, 110 insertions(+), 43 deletions(-)
CFS Desktop Performance
Yes it will be interesting to see how CFS compares to Con Kolivas's 2.6.22-ck1 patch set in performance on the desktop. A simple test on my Gentoo machine running this program in Xfce Terminal:
#!/bin/bash
# termspeed program - tests rendering speed on a terminal screen in X.
time seq -f 'teeeeeeeeeeeeeeeeeeeeeeeeeeeeeest %g' 1000000
vanilla 2.6.22.3:
terminal window visible: real time was 61 seconds.
terminal window covered: real time was 32 seconds.
terminal window shaded: real time was 129 seconds.
2.6.22-ck1:
terminal window visible: real time was 25 seconds.
terminal window covered: real time was 13 seconds.
terminal window shaded: real time was 22 seconds.
Both kernels were compiled with exactly the same settings except that 2.6.22-ck1 has the swap prefetch turned on.. other than that everything was exactly the same running on the same computer and right after cold reboots.
Overall, the X desktop using 2.6.22-ck1 feels more responsive too.
I hope CFS does not end up sucking on the desktop compared to the 2.6.22-ck1 design... since we are probably now stuck with it regardless.
You know, you could have
You know, you could have spent less time writing text and more time testing 2.6.22.5 with the CFS patch if you really wanted to compare the performance yourself. After all, you have already run two different kernels.
http://people.redhat.com/mingo/cfs-scheduler/
And you could also explain how your test measures scheduler performance. In my own experience, the time it takes to render a piece of text in a terminal emulator depends a lot on stuff like the window buffer size and how it aligns to the text you print, giving sometimes random performance.
Re: You know, you could have
Yeah its me, the guy that wrote what you responded to.
And perhaps you could spend less time trying to figure out how to decide that the ck patch doesn't kick ass and more time trying to understand why it does.
What is there to explain? Duh.. same test bed, same conditions, repeatable results... 'nuf said.
"What is there to explain?
"What is there to explain? Duh.. same test bed, same conditions, repeatable results... 'nuf said"
why don't you explain the reason not to include cfs patched kernel in the results, and claim that sd (or -ck in general) is better without giving any proof?
What you need to explain is
What you need to explain is why, in a story about CFS, you compared the -ck patchset with the vanilla kernel, i.e., without using CFS. What were you trying to prove? Why did you ask a question at the end of your original post wondering how CFS would perform instead of, you know, actually applying the patch and testing the performance? How does your test relate to scheduling? Those are the questions you have to answer after your first post.
Explanation?
The original post was a comment.. no actual point was to be made there. Simply to state an opinion and show a result of a simple test showing that the ck patch makes a very noticeable practical improvement in desktop performance over the standard kernel of similar version. And the hope that the decision to redo in a last minute frenzy all the work put in by Con, and subsequently pissing him off to the point that he quit working on it for ever, was going to actually work out for the best and not cause the kernel to instead end up with something less than what could have been. But, after playing around with the back ported patch for 2.6.22.5, it seems that Ingo has succeeded in attaining the same level of performance that Con has.
Re: CFS Desktop Performance
I think testing rendering speed is not the way to test it?
It depends much on the way how often the terminal gets repainted.
But i haven't tested ck1 myself, so probably it is whatever it is.
Desktop responsiveness
Desktop responsiveness primarily depends on CPU cache sizes and whether video buffer swapping is synced to the horizontal blanking. Next is probably the GTK theme you use...
I really don't notice any difference between the old, staircase, and fair schedulers. They don't seem to be the right solution for the current state of annoyingly sluggish Linux desktop experience...
2.6.22.5 with CFS Patch
Hello its me again.
Ok I ran 2.6.22.5 with the latest CFS patch applied. Here are the results from running the same simple terminal benchmark program as above, all settings and conditions the same as above too.
vanilla 2.6.22.5:
terminal window visible: real time was 59 seconds.
terminal window covered: real time was 32 seconds.
terminal window shaded: real time was 135 seconds.
terminal window iconified: real time was 160 seconds.
2.6.22.5 with latest CFS patch applied:
terminal window visible: real time was 27 seconds.
terminal window covered: real time was 13 seconds.
terminal window shaded: real time was 21 seconds.
terminal window iconified: real time was 21 seconds.
compare to CK's -
2.6.22-ck1:
terminal window visible: real time was 25 seconds.
terminal window covered: real time was 13 seconds.
terminal window shaded: real time was 22 seconds.
terminal window iconified: real time was 22 seconds.
The overall response feels identical to CK's as well.
I'm happy! :-)
There's something obviously
There's something obviously wrong with your results for the vanilla kernel: shaded / iconified should not take more time than visible.
I tried here and indeed it doesn't.
As a coincidence, I discovered that GNOME-Terminal is 3 times faster on this test than xterm! Good to know!
I know it shouldn't but it does
I know it shouldn't but it does. Maybe it has something to do with the window manager. I'm running Xfce4 on Gentoo. I see the same results on another box setup the same way.
That is good to know about Gnome Terminal.
Meaningless in context?
Something to consider is desktop user experience is all about latency. High latency results in poor user experience. Low latency usually results in good user experience. The benchmark provided does not seem to measure latency at all. In fact, it seems to be measuring throughput of some set of operations. Throughput and latency tend to be enemies of each other. In other words, systems which provide high throughput tend to result in poor latency. Systems which provide low latency tend to provide for poor throughput. Yet the benchmark seems to indicate throughput sucked on the stock kernel so one would actually assume the user experience would be, by far, drastically better with the stock kernel.
Frankly, I'd like to know more about this benchmark, the system it ran on, number of runs, reproducability, etc...because it seems to have no meaning in the current context. What the heck is it doing? What is it measuring? Why is the stock kernel so poor? What is it really measuring? Frankly, when I look at those results, my immediate impression is that something stinks because the differences are so huge...and seemingly un-intuative. Add in the point that tests which should be faster, save for bugs in the benchmark, are actually slower than they should be, even on the same kernel, something isn't right. At this point, without MUCH additional information, I'm more than happy to ignore those benmarks as on the surface they have every indication of being completely meaningless, flat out wrong, and just plain fictional.
H-mmm
"At this point, without MUCH additional information, I'm more than happy to ignore those benmarks as on the surface they have every indication of being completely meaningless, flat out wrong, and just plain fictional."
What would it take you.. maybe 2 minutes to copy the two line shell script and run it?? You will get the similar results whether you run it in xterm, urxvt, or xfce terminal. I stated the kernel version and window manager.
Or is it easier to just ignore? Whatever.
Absurd pride
"So CFS has turned out to be a pretty robust codebase.)"
No need to sell us on it, Ingo, since any better alternative would be quickly rejected for "technical reasons", and then madly reimplemented by yourself. Why shouldn't the code be robust? The algorithm was proven by Kolivas. You are a fraud.
Baseless accusations
Considering that Ingo had started on CFS before Con had published the SD scheduler... your comment is rather lame. And whats with this fanboi-ing going on around Con? He had some very nice patches but I don't see how that'd create a following of people that know ziltch about kernel development or any development at all trumpetting anything to do with SD and bashing everything to do with CFS.
How about YOU getting the
How about YOU getting the facts right? http://kerneltrap.org/node/14022 and STFU.
Absurd pride
Absurd pride , **** you.....
Mr Ingo, you are so cool.......
many thanks and support for what you have done....
Ingo Molnar has already given credit to Con
I think Ingo is doing a great job, and deserves a lot more respect from you. I also get the impression that Con had more than just some great ideas. However, sometimes decisions have to be made on technical & pragmatic grounds that may offend some people, this is unfortunate.
From my reading of the various aspects: yes it is a pity that Con's code was not more fully accepted, but his input has been both incorporated & respected by Ingo. I think if Con had not had severe health problems, the story would have been quite different - and more to your liking.
There is no call to insult Ingo, though you have every right to disagree with him if you so wish, but please do so in a maturte way rather than lashing out in a temper tantrum!
-Nivag
So because Ingo made a
So because Ingo made a proper implementation of Con's good algorithm, but sucky implementation, he's a fraud?
You're an idiot.
- Besides, the algorithm isn't even the same, just a part of the basic idea is.
I don't think so
Ingo is no fraud, and CFS is a very well written piece of code the majority of which Ingo is responsible for. The issue with Con was that he was handled poorly. Trolling comments from Linus Torvalds of all people - absurd suggestions that Con did not help users - and Ingo disappearing into a hole to implement CFS, all conspired against Con but it was not intentional, just poor management by a noisy and volatile LKML.
It's also interesting how you can shout insults at Ingo under the guise of anonymity. If you really believe this, why not express your opinion alongside your identity?
The diff between Info and CK
Can't remember where I read it, but here is the *best* quote regarding the difference between Con and Ingo out there, "The difference between Ingo Molnar and Con Kolivas is that Ingo has had more code rejected from the Linux kernel than Con has had accepted".
That really does say alot in who has been around longer. Look at Ingo's -rt branch or the Exec-shield stuff. That is a LOT of code that still isn't in mainline for technical reasons. It just needs more work.
actually, I'd go so far as
actually, I'd go so far as to say the difference between Con and Ingo is this:
Ingo releases updates and fixes.
Con throws a hissy fit and quits.
Eh... I didn't see it that way
Ingo has had his share of non-robust patches. I seem to remember O(1) had numerous hiccups along the way, for instance. I took this more as a "Well, this turned out well. *whew*"
--
Program Intellivision and play Space Patrol!
bad logic
So by your logic, Japan, Korea, China, and just about every other country in the world which takes a product, idiom, or idea and improves or simply reimplements/repackages, is a fraud.
You just gatta love that back-assward logic. Please don't let irrational politics drive your desire to bash what is quickly proving to be a much superior technological solution.
Amount of changes
"There are nearly 100 changes - they do add up to a significant total linecount change."
None of them fixed serious bug. Just improving speed, tiny regressions and debug capabilities.
So.. How come Linus do not object in merging such amount of code like he does with other developers?
Linus always handles new
Linus always handles new code like that: with new code there's much less "regression" potential relative to the last stable release, so more leeway is given.
But I would disagree with your characterisation of those changes: most of them seem to be fixes and cleanups which are acceptable material up to the final -rc iteration, even in the case of subsystems where there's already a significant QA investment in an existing codebase.
With nearly 1 million lines of code being changed or added in every Linux kernel release (2.6.23 has already more than 720 thousand lines of source-code flux, with more than 6800 source files changed) it would not be practical at all to enforce a complete freeze after -rc1.
Only when Linus declares "let us try to make this the final -rc" is the kernel codebase truly frozen down to all but the most critical bugfixes.
What?!
Are you saying "RCn-1" is the new "RC1"?
RC stands for Release Candidate. Ideally, only critical bugfixes and absolutely safe patches should go in starting at RC1. They haven't been as strict about this as they should, hence the quote "RC2 is the new RC1 is a disease." The way you make it sound, though, it's closer to "let's have a bunch of RCs until we're sick of it, and then it's really a release candidate."
--
Program Intellivision and play Space Patrol!
"RCn-1" is the new "RC1"
That's the way it's been for a while. I've noticed a number of projects make RC releases that are _known_ to be not release ready. It's just an indiciation that a project is approaching a stable release.
You will notice there was no
You will notice there was no request for Linus to pull the v20 version. The pull request was for a much smaller, bug fix only, git tree.