Announcement

Collapse
No announcement yet.

The ~200 Line Linux Kernel Patch That Does Wonders

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by raj7095 View Post
    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 <yong.zhang0@gmail.com>
    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 <mfwitten@gmail.com>
    Reported-by: Christian Kujau <christian@nerdbynature.de>
    Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
    ---
    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:


    Originally posted by patch -p1 --dry-run < ../2.6.37_CFS.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

    Comment


    • 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/

      Comment


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

        so no guarantees that it'll boot for you

        Comment


        • 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 !

          Comment


          • Originally posted by raj7095 View Post
            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?

            Comment


            • Originally posted by martinus View Post
              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?
              i am pretty sure that the bfs version is 0.363, thats the only one available for kernel 2.6.37. i tried using the ck patchset, but it just won't boot for me.

              Comment


              • btw, kerneloftruth, thanks for all the patches. imma try em all out now.

                Comment


                • Originally posted by raj7095 View Post
                  i am pretty sure that the bfs version is 0.363, thats the only one available for kernel 2.6.37. i tried using the ck patchset, but it just won't boot for me.
                  ok, understand. but I'm still wondering what you meant when you said "much worse multitasking"?

                  Comment


                  • Originally posted by martinus View Post
                    ok, understand. but I'm still wondering what you meant when you said "much worse multitasking"?
                    for example, when i am compiling anything with 4 jobs on my machine, bfs 0.363 stalls a lot and the desktop interactivity is horrible, but with bfs 0.360, it was smooth, extremely smooth, not a single stall.

                    Comment


                    • Originally posted by raj7095 View Post
                      for example, when i am compiling anything with 4 jobs on my machine, bfs 0.363 stalls a lot and the desktop interactivity is horrible, but with bfs 0.360, it was smooth, extremely smooth, not a single stall.
                      ermm, is that on the same "nice" level and the same scheduling policy (SCHED_NORMAL)? In that case I am more surprised about your good results under 0.360. The whole idea of CF (="completely fair") and BF (="super simple") scheduling is the even distribution of the cpu resource without policy in the kernel.

                      On my machine everything labour intensive is started at scheduling policy SCHED_IDLEPRIO (I used to change the "nice" level in the past which also affects "i/o nice") and all desktop activity, sound, films are totally smooth.

                      I do wonder why people go through the hassle of complicated kernel patches when a straightforward scheduler and some user policy achieve so much better.

                      Comment


                      • Originally posted by martinus View Post
                        ermm, is that on the same "nice" level and the same scheduling policy (SCHED_NORMAL)? In that case I am more surprised about your good results under 0.360. The whole idea of CF (="completely fair") and BF (="super simple") scheduling is the even distribution of the cpu resource without policy in the kernel.

                        On my machine everything labour intensive is started at scheduling policy SCHED_IDLEPRIO (I used to change the "nice" level in the past which also affects "i/o nice") and all desktop activity, sound, films are totally smooth.

                        I do wonder why people go through the hassle of complicated kernel patches when a straightforward scheduler and some user policy achieve so much better.
                        yeah, i tried everything. i put labour intensive tasks in idleprio, the ones that need interactivity in sched_iso, nice level doesnt make a huge difference for me, not that i noticed. but the thing is, even if i try all those, it still doesnt beat bfs 0.360 without any adjustments at all, it gets close, but it doesn't. i even put X in sched_iso and set rr_interval, sched_iso etc.

                        Comment


                        • Originally posted by raj7095 View Post
                          yeah, i tried everything. i put labour intensive tasks in idleprio, the ones that need interactivity in sched_iso, nice level doesnt make a huge difference for me, not that i noticed. but the thing is, even if i try all those, it still doesnt beat bfs 0.360 without any adjustments at all, it gets close, but it doesn't. i even put X in sched_iso and set rr_interval, sched_iso etc.
                          if you ever find the reason for this let us know

                          I am writing this reply on a 4 core machine without SMT, currently on 2.6.37-ck1 which includes bfs 0.363, compiling a kernel in the background (make -j 8), while playing a google tech talk video about quantum computing and doing the wobbly windows thingy. 8-)

                          All 4 cores are on 100%, load average is roughly 9. The user experience is as smooth as if the kernel compilation didn't happen in the background. Only the cpu fan is significantly louder than normal. 8-) So obviously I am not experiencing your regression...

                          Comment


                          • Originally posted by martinus View Post
                            if you ever find the reason for this let us know

                            I am writing this reply on a 4 core machine without SMT, currently on 2.6.37-ck1 which includes bfs 0.363, compiling a kernel in the background (make -j 8), while playing a google tech talk video about quantum computing and doing the wobbly windows thingy. 8-)

                            All 4 cores are on 100%, load average is roughly 9. The user experience is as smooth as if the kernel compilation didn't happen in the background. Only the cpu fan is significantly louder than normal. 8-) So obviously I am not experiencing your regression...
                            u say u dont have smt, correct? i do, on a dual core, maybe that makes a difference in the new bfs. oh well, i will just stick to kerneloftruth's patches or the 2.6.36 version of zen kernel.

                            Comment


                            • Originally posted by raj7095 View Post
                              u say u dont have smt, correct? i do, on a dual core, maybe that makes a difference in the new bfs. oh well, i will just stick to kerneloftruth's patches or the 2.6.36 version of zen kernel.
                              any experience with my 2 patchsets yet ?

                              Comment


                              • Originally posted by kernelOfTruth View Post
                                any experience with my 2 patchsets yet ?
                                the first patchset worked perfectly, the second patch fails at compile time for me. what does the second patch do anyways?

                                Comment

                                Working...
                                X