The ~200 Line Linux Kernel Patch That Does Wonders

[martinus]

hey, anyone notice how much worse bfs' multitasking is in zen kernel 2.6.37 compared to 2.6.36?

I don't use zen. I use vanilla with ck and I cannot confirm your statement. On what observation is it based? What type of machine? What bfs version?

[kernelOfTruth]

ok, I forgot a patchset

"[wake_afine fixes-improvements 0/3] Introduction"

*click*

this should cleanly apply on top of the previous patch

I've also compile-tested this and it worked fine for me

Have fun !

[kernelOfTruth]

I compile-tested the tested but didn't boot-tested it

so no guarantees that it'll boot for you

[kernelOfTruth]

or if you'd like to try out a full-blown kernel with lots of additional goodies:

http://zen-kernel.org/

Git based installation

http://git.zen-kernel.org/zen-stable/

[kernelOfTruth]

i dont really care about the throughput on my machine though, of course there is a minimum requirement but still. is the newer cfs faster in any way? if it is, can someone guide me to some instructions or a pre-patched kernel?

ok, *click*
here you are (the link is 1 month valid)

the patch includes the following:

Linus,

Please pull the latest sched-core-for-linus git tree from:

git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git sched-core-for-linus

The biggest user-visible change is the new auto-group scheduling feature - it can be
enabled via CONFIG_SCHED_AUTOGROUP=y (disabled by default).

With this feature enabled the scheduler protects tasks in different terminals/ttys
from each other.

I tried a few typical workloads like make -j20 kernel builds, hackbench or lots of
CPU-intense loops - Firefox interactivity was not impacted in any measurable way
while the runqueues were permanently overloaded with 100 or more tasks per CPU. (!)

So it's unconditional goodness on the desktop and it is perhaps one of the biggest
and most visible interactivity improvements achieved by the Linux scheduler, ever.
Group scheduling is a league of its own in terms of interactivity and all the group
scheduling integration pain of the past two years seems to have paid off for the
Linux desktop, finally.

Thanks,

Ingo

------------------>
Dario Faggioli (1):
sched: Make pushable_tasks CONFIG_SMP dependant

Dhaval Giani (1):
cpu: Remove unused variable

Eric Dumazet (1):
printk: Use this_cpu_{read|write} api on printk_pending

Erik Gilling (1):
sched: Make task dump print all 15 chars of proc comm

Gerald Schaefer (1):
mutexes, sched: Introduce arch_mutex_cpu_relax()

KOSAKI Motohiro (1):
sched: Make sched_param argument static in sched_setscheduler() callers

Mike Galbraith (3):
sched: Add 'autogroup' scheduling feature: automated per session task groups
sched, autogroup: Fix potential access to freed memory
sched, autogroup: Fix reference leak

NeilBrown (1):
sched: Change wait_for_completion_*_timeout() to return a signed long

Nikanth Karthikesan (1):
sched: Remove unused argument dest_cpu to migrate_task()

Paul Turner (11):
sched: Fix load corruption from update_cfs_shares()
sched: Fix update_cfs_load() synchronization
sched: Introduce hierarchal order on shares update list
sched: Add sysctl_sched_shares_window
sched: Update shares on idle_balance
sched: Implement demand based update_cfs_load()
sched: Allow update_cfs_load() to update global load
sched: Update tg->shares after cpu.shares write
sched: Fix unregister_fair_sched_group()
sched: Move periodic share updates to entity_tick()
sched: Fix interactivity bug by charging unaccounted run-time on entity re-weight

Peter Zijlstra (7):
sched: Simplify cpu-hot-unplug task migration
sched: Rewrite tg_shares_up)
sched: Implement on-demand (active) cfs_rq list
sched: Make tg_shares_up() walk on-demand
sched: Fix UP build breakage
cpu: Remove incorrect BUG_ON
sched: Add some clock info to sched_debug

Yong Zhang (1):
sched: Remove redundant CONFIG_CGROUP_SCHED ifdef

------------------>
Hillf Danton (1):
sched: Fix strncmp operation

Mike Galbraith (2):
sched: Fix struct autogroup memory leak
sched: Move sched_autogroup_exit() to free_signal_struct()

Peter Zijlstra (1):
sched: Constify function scope static struct sched_param usage

Yong Zhang (2):
sched: Consolidate the name of root_task_group and init_task_group
sched: Mark autogroup_init() __init

------------------>
Bharata B Rao (2):
sched: Reinstate group names in /proc/sched_debug
sched: Display autogroup names in /proc/sched_debug

Mike Galbraith (2):
sched, autogroup: Fix CONFIG_RT_GROUP_SCHED sched_setscheduler() failure
sched: Fix signed unsigned comparison in check_preempt_tick()

Paul Turner (1):
sched: Update effective_load() to use global share weights

Peter Zijlstra (1):
sched, cgroup: Use exit hook to avoid use-after-free crash

Yong Zhang (1):
sched: Replace rq->bkl_count with rq->rq_sched_info.bkl_count

[RFC -v6 PATCH 0/8] directed yield for Pause Loop Exiting
(patchset, for fixing problems with virtualization & KVM)

[patch 0/5] scheduler fixlets
(patchset fixing some balancing problems in CFS from Google)

From: Yong Zhang <[email protected]>
Subject: [PATCH] sched: tg->se->load should be initialised to tg->shares

Michael reported that when enable autogroup on UP, system
responsiveness becomes very bad.
Because in init_tg_cfs_entry() we initialise se->load
to 0 instead of tg->shares, in the end we have 0-weight
sched entity on rq, then lead to misbehavior.

Reported-by: Michael Witten <[email protected]>
Reported-by: Christian Kujau <[email protected]>
Signed-off-by: Yong Zhang <[email protected]>
---
kernel/sched.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

(UP == uniprocessor fix for autogroup)







instructions:

extract 2.6.37 tarball

tar xjpf linux-2.6.37.tar.bz2 -C .
(to the current directory)

pretend to apply the patch:

patching file arch/Kconfig
patching file arch/s390/include/asm/mutex.h
patching file arch/s390/Kconfig
patching file Documentation/kernel-parameters.txt
patching file fs/proc/base.c
patching file include/linux/completion.h
patching file include/linux/init_task.h
patching file include/linux/kvm_host.h
patching file include/linux/mutex.h
patching file include/linux/sched.h
patching file include/linux/sched.h.orig
patching file init/Kconfig
patching file kernel/cpu.c
patching file kernel/fork.c
patching file kernel/fork.c.orig
patching file kernel/irq/manage.c
patching file kernel/kthread.c
patching file kernel/mutex.c
patching file kernel/pid.c
patching file kernel/printk.c
patching file kernel/sched_autogroup.c
patching file kernel/sched_autogroup.h
patching file kernel/sched.c
patching file kernel/sched_clock.c
patching file kernel/sched.c.orig
patching file kernel/sched_debug.c
patching file kernel/sched_fair.c
patching file kernel/sched_fair.c.orig
patching file kernel/sched_features.h
patching file kernel/sched_rt.c
patching file kernel/softirq.c
patching file kernel/sys.c
patching file kernel/sysctl.c
patching file kernel/trace/trace_selftest.c
patching file kernel/watchdog.c
patching file virt/kvm/kvm_main.c

remove the --dry-run
when it applies cleanly

I have the following enabled in my kernel-config:

CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_NS is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_CGROUP_BFQIO is not set

[raj7095]

i dont really care about the throughput on my machine though, of course there is a minimum requirement but still. is the newer cfs faster in any way? if it is, can someone guide me to some instructions or a pre-patched kernel?

[Thatguy]

You trade some throughput for more resposniveness, there are ways around this however, its just more complicated to code for.

This patch is really a hack in alot of ways. But it might work great for desktop users. It'll suck for servers. Lots of reqource contention. It'll suck for scientific uses etc where you need to jam through maximum data as fast as you can.

Its really very application specific. I tried this patch on a build. I wasn't very impressed.

[raj7095]

also, how much performance gain does the cfs from kernel 2.6.38 give you compared to the cfs in kernel 2.6.37?

[raj7095]

how do you use cfs from 2.6.38 in 2.6.37?

[kernelOfTruth]

hey, anyone notice how much worse bfs' multitasking is in zen kernel 2.6.37 compared to 2.6.36?

yeah,

weird - isn't it ?

therefore I'm using 2.6.37 with CFS from 2.6.38

no idea what changed in vanilla/mainline so that performance has to suffer that much with BFS

BFS was always better than CFS - hopefully Con will push out some improvements over time