"Lots of scheduler updates in the past few days, done by many people," noted Ingo Molnar, going on to describe the more significant updates. "Most importantly, the SMP latency problems reported and debugged by Mike Galbraith should be fixed for good now." Ingo noted that the current code base was looking stable and was likely to be merged into the upcoming 2.6.24 kernel, "so please give it a good workout and let us know if there's anything bad going on. (If this works out fine then i'll propagate these changes back into the CFS backport, for wider testing.)" He went on to describe the other main changes in the development branch of the process scheduler:
"I've also included the latest and greatest group-fairness scheduling patch from Srivatsa Vaddagiri, which can now be used without containers as well (in a simplified, each-uid-gets-its-fair-share mode). This feature (CONFIG_FAIR_USER_SCHED) is now default-enabled.
"Peter Zijlstra has been busy enhancing the math of the scheduler: we've got the new 'vslice' forked-task code that should enable snappier shell commands during load while still keeping kbuild workloads in check."
From: Ingo Molnar <mingo@...>
Subject: [git] CFS-devel, latest code
Date: Sep 24, 5:45 pm 2007
The latest sched-devel.git tree can be pulled from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git
Lots of scheduler updates in the past few days, done by many people.
Most importantly, the SMP latency problems reported and debugged by Mike
Galbraith should be fixed for good now.
I've also included the latest and greatest group-fairness scheduling
patch from Srivatsa Vaddagiri, which can now be used without containers
as well (in a simplified, each-uid-gets-its-fair-share mode). This
feature (CONFIG_FAIR_USER_SCHED) is now default-enabled.
Peter Zijlstra has been busy enhancing the math of the scheduler: we've
got the new 'vslice' forked-task code that should enable snappier shell
commands during load while still keeping kbuild workloads in check.
On my testsystems this codebase starts looking like something that could
be merged into v2.6.24, so please give it a good workout and let us know
if there's anything bad going on. (If this works out fine then i'll
propagate these changes back into the CFS backport, for wider testing.)
Ingo
----------------------------------------->
the shortlog relative to 2.6.23-rc7:
Dmitry Adamushko (8):
sched: clean up struct load_stat
sched: clean up schedstat block in dequeue_entity()
sched: sched_setscheduler() fix
sched: add set_curr_task() calls
sched: do not keep current in the tree and get rid of sched_entity::fair_key
sched: optimize task_new_fair()
sched: simplify sched_class::yield_task()
sched: rework enqueue/dequeue_entity() to get rid of set_curr_task()
Ingo Molnar (41):
sched: fix new-task method
sched: resched task in task_new_fair()
sched: small sched_debug cleanup
sched: debug: track maximum 'slice'
sched: uniform tunings
sched: use constants if !CONFIG_SCHED_DEBUG
sched: remove stat_gran
sched: remove precise CPU load
sched: remove precise CPU load calculations #2
sched: track cfs_rq->curr on !group-scheduling too
sched: cleanup: simplify cfs_rq_curr() methods
sched: uninline __enqueue_entity()/__dequeue_entity()
sched: speed up update_load_add/_sub()
sched: clean up calc_weighted()
sched: introduce se->vruntime
sched: move sched_feat() definitions
sched: optimize vruntime based scheduling
sched: simplify check_preempt() methods
sched: wakeup granularity fix
sched: add se->vruntime debugging
sched: add more vruntime statistics
sched: debug: update exec_clock only when SCHED_DEBUG
sched: remove wait_runtime limit
sched: remove wait_runtime fields and features
sched: x86: allow single-depth wchan output
sched: fix delay accounting performance regression
sched: prettify /proc/sched_debug output
sched: enhance debug output
sched: kernel/sched_fair.c whitespace cleanups
sched: fair-group sched, cleanups
sched: enable CONFIG_FAIR_GROUP_SCHED=y by default
sched debug: BKL usage statistics
sched: remove unneeded tunables
sched debug: print settings
sched debug: more width for parameter printouts
sched: entity_key() fix
sched: remove condition from set_task_cpu()
sched: remove last_min_vruntime effect
sched: undo some of the recent changes
sched: fix place_entity()
sched: fix sched_fork()
Matthias Kaehlcke (1):
sched: use list_for_each_entry_safe() in __wake_up_common()
Mike Galbraith (2):
sched: fix SMP migration latencies
sched: fix formatting of /proc/sched_debug
Peter Zijlstra (10):
sched: simplify SCHED_FEAT_* code
sched: new task placement for vruntime
sched: simplify adaptive latency
sched: clean up new task placement
sched: add tree based averages
sched: handle vruntime overflow
sched: better min_vruntime tracking
sched: add vslice
sched debug: check spread
sched: max_vruntime() simplification
Srivatsa Vaddagiri (7):
sched: group-scheduler core
sched: revert recent removal of set_curr_task()
sched: fix minor bug in yield
sched: print nr_running and load in /proc/sched_debug
sched: print &rq->cfs stats
sched: clean up code under CONFIG_FAIR_GROUP_SCHED
sched: add fair-user scheduler
arch/i386/Kconfig | 11
include/linux/sched.h | 45 +--
init/Kconfig | 21 +
kernel/sched.c | 547 +++++++++++++++++++++++++------------
kernel/sched_debug.c | 248 +++++++++++------
kernel/sched_fair.c | 692 +++++++++++++++++-------------------------------
kernel/sched_idletask.c | 5
kernel/sched_rt.c | 12
kernel/sched_stats.h | 4
kernel/sysctl.c | 22 -
kernel/user.c | 43 ++
11 files changed, 906 insertions(+), 744 deletions(-)
-
Interesting discussion
The discussion in the thread is interesting too. As long as you disable CONFIG_FAIR_USER_SCHED (which has some latency bugs), Mike Galbraith has described this as the
best scheduler he has ever tested.
Yeah, but...
Yeah, but it still gets outperformed by Con Kolivas SD (staircase-dead) scheduler?
Troll school lesson one:
Sheesh, the trolls these days.
Troll school lesson one: You should at least pretend that you have something significant to say, and pretend that you have at least a tiny bit of evidence to back up your claims.
Kernel Party?
The Kernel Party has forbidden the names SD, Con Kolivas, and Roman Zippel in Kernel communications. Party Leader Ingo Molnar has decreed that Kolivas and Zippel are hooligans and a threat to mailing list harmony. Love the Good Process Scheduler.
Apparently you didn't read
Apparently you didn't read the above lesson on trolling. I suggest you do.
Apparently you can't seem to
Apparently you can't seem to recognize a joke. I suggest you do.
Congratulations!
If your intention was to write a ... joke, you succeeded in removing all traces of it being a joke and you also managed to mask it as a petty insult. Quite a feat! =)
CFS ready for prime time?
Really great to see such large changes in code that is merged in the main trunk. What a cock up.
CFS development version
You should read KernelTrap more often: for example last week's article about Jens Axboe's linux-2.6-block development tree.
It's the development version of the code, not meant for 2.6.23. Now that 2.6.24 is close to be opened, kernel developers are posting their development branches.
This article is about the scheduler development tree, with new features like group scheduling.
In addition to what the
In addition to what the above commenter said, most of the commits are just one–three-line changes: cleanups, etc.
RE: CFS ready for prime time?
Actually, if you read the shortlog for 2.6.23-rc8, you will note that there isn't a single CFS or related changeset which was merged.
Reading is Fundamental!
Indeed! From Ingo's own email (reinforcing what you just said):
Emphasis added. Of course, we're probably just keeping the trolls well fed. :-P--
Program Intellivision and play Space Patrol!
Too bad that CK's army of
Too bad that CK's army of trolls didn't disband when he left...
put blame where it's due
Don't blame CK for the trolls. Trolling seems to be a social (psychological?) phenomenon. Just look at the trolls that jump to the defence of Microsoft whenever anyone poo-poohs one of their products.
The blame is entirely
The blame is entirely CK's... He decided to make his own little universe apart from the kernel, thus creating the atmosphere for this whole CK vs. "core", and the fanboy army.
You got it wrong
The blame is entirely Ingo Molnar's and his loyal band of sycophants. They refused to accept a real improvement, then deceptively developed a cheap immitation. That created the atmosphere of distrust that persists today.
Without CK's patchs my machine's interactivity sucks.
Without CK's patchs my
Have you reported this already?
charge $$$
anonymous posting turns everyone into a troll.
kt should institute a no-anonymous-posting policy, and make obntaining a posting account a one-time $5 cost