Page 1 of 7 123 ... LastLast
Results 1 to 10 of 62

Thread: New Kernel Speed up Patch File from Mike Galbraith?

  1. #1
    Join Date
    Mar 2010
    Location
    Austin - Texas
    Posts
    10,500
    Blog Entries
    48

    Smile New Kernel Speed up Patch File from Mike Galbraith?

    Has anyone seen this stuff about a kernel speed up patch? Here is one Article

    The Linux desktop may soon be a lot faster - Computerworld Blogs

    And Yet another even stranger kernel speed up here:

    Alternative To The "200 Lines Kernel Patch That Does Wonders" Which You Can Use Right Away ~ Web Upd8: Ubuntu / Linux blog

    I have no idea if any of this stuff is true, but lets see some of our high power guys check it out and let us know what is true or not.

    Thank You,
    My Blog: https://forums.opensuse.org/blogs/jdmcdaniel3/

    Software efficiency halves every 18 months, thus compensating for Moore's Law

    Its James again from Austin, Texas

  2. #2
    Join Date
    Jun 2008
    Location
    Berlin
    Posts
    2,108

    Default Re: New Kernel Speed up Patch File from Mike Galbraith?

    There actually have been threads about this issue, and yes, it's "true" (there are some pretty impressive benchmarks on that), this patch will be part of upcoming Linux Kernels.

  3. #3
    Join Date
    Jun 2008
    Location
    UTC+10
    Posts
    9,941
    Blog Entries
    4

    Default Re: New Kernel Speed up Patch File from Mike Galbraith?

    SJVN may be waxing a bit optimistic. I believe the purpose of the original patch and the followup shortcut is to improve interactivity under hefty load, e.g. large compiles. If you are not doing anything strenuous on your CPU, you probably won't notice any improvement. So as such it isn't a kernel speed up patch, but rather an interactivity improvement patch. This is the original post and the comments attached to it are more informative than second or third hand speculations.

    LKML: Mike Galbraith: [RFC/RFT PATCH] sched: automated per tty task groups

  4. #4
    Join Date
    Mar 2008
    Location
    Europe
    Posts
    25,867
    Blog Entries
    30

    Default Re: New Kernel Speed up Patch File from Mike Galbraith?

    There has been a lot on this 'new' faster kernel. Yet some say (such as Lennart Poettering, a RedHat developer ) one does not even need that patch in the new kernel to get the better performance.

    I am still trying to wrap my head around this interesting post (which is in DIRECT reply to the faster kernel claims): Alternative To The "200 Lines Kernel Patch That Does Wonders" Which You Can Use Right Away ~ Web Upd8: Ubuntu / Linux blog which jdmcdaniel3 also quotes. In the end, I decided I was simply too thick and not experienced enough in Linux to understand the alternative to the 200 line kernel patch. Is that applicable to all kernels? Is it applicable to openSUSE in addition to Red Hat ?

    ... I'm hoping someone can provide some interesting guidance here.

  5. #5
    Join Date
    Mar 2008
    Location
    Europe
    Posts
    25,867
    Blog Entries
    30

    Default Re: New Kernel Speed up Patch File from Mike Galbraith?

    Quote Originally Posted by ken_yap View Post
    SJVN may be waxing a bit optimistic. I believe the purpose of the original patch and the followup shortcut is to improve interactivity under hefty load, e.g. large compiles. If you are not doing anything strenuous on your CPU, you probably won't notice any improvement.
    Hmmm ... how about rendering video ?

    There are times when I setup a batch job, and have my Core i7 920 busy rendering multiple videos for 12hours or more at a time.

  6. #6
    Join Date
    Jun 2008
    Location
    UTC+10
    Posts
    9,941
    Blog Entries
    4

    Default Re: New Kernel Speed up Patch File from Mike Galbraith?

    Yes, transcoding video and music would probably load the CPU.

  7. #7
    Join Date
    Mar 2010
    Location
    Austin - Texas
    Posts
    10,500
    Blog Entries
    48

    Smile Re: New Kernel Speed up Patch File from Mike Galbraith?

    I found this which was reported to be the speed up patch, but I surely could be wrong. If one had the source code for a kernel, how would this patch be applied for testing.

    Code:
        
    Enter your search termsSubmit search formWeblkml.org
    Subject    [RFC/RFT PATCH] sched: automated per tty task groups
    From    Mike Galbraith <>
    Date    Tue, 19 Oct 2010 11:16:04 +0200
    
    Greetings,
    
    Comments, suggestions etc highly welcome.
    
    This patch implements an idea from Linus, to automatically create task groups
    per tty, to improve desktop interactivity under hefty load such as kbuild.  The
    feature is enabled from boot by default,  The default setting can be changed via
    the boot option ttysched=0, and can be can be turned on or off on the fly via
    echo [01] > /proc/sys/kernel/sched_tty_sched_enabled.
    A 100% hog overhead measurement proggy pinned to the same CPU as a make -j10
    
    pert/s:      229 >5484.43us:       41 min:  0.15 max:12069.42 avg:2193.81 sum/s:502382us overhead:50.24%
    pert/s:      222 >5652.28us:       43 min:  0.46 max:12077.31 avg:2248.56 sum/s:499181us overhead:49.92%
    pert/s:      211 >5809.38us:       43 min:  0.16 max:12064.78 avg:2381.70 sum/s:502538us overhead:50.25%
    pert/s:      223 >6147.92us:       43 min:  0.15 max:16107.46 avg:2282.17 sum/s:508925us overhead:50.49%
    pert/s:      218 >6252.64us:       43 min:  0.16 max:12066.13 avg:2324.11 sum/s:506656us overhead:50.27%
    
    Signed-off-by: Mike Galbraith <efault@gmx.de>
    
    ---
     drivers/char/tty_io.c |    2 
     include/linux/sched.h |   14 +++++
     include/linux/tty.h   |    3 +
     init/Kconfig          |   13 +++++
     kernel/sched.c        |    9 +++
     kernel/sched_tty.c    |  128 ++++++++++++++++++++++++++++++++++++++++++++++++++
     kernel/sched_tty.h    |    7 ++
     kernel/sysctl.c       |   11 ++++
     8 files changed, 186 insertions(+), 1 deletion(-)
    Index: linux-2.6.36.git/include/linux/sched.h
    ===================================================================
    --- linux-2.6.36.git.orig/include/linux/sched.h
    +++ linux-2.6.36.git/include/linux/sched.h
    @@ -1900,6 +1900,20 @@ int sched_rt_handler(struct ctl_table *t
     
     extern unsigned int sysctl_sched_compat_yield;
     
    +#ifdef CONFIG_SCHED_DESKTOP
    +int sched_tty_sched_handler(struct ctl_table *table, int write,
    +        void __user *buffer, size_t *lenp,
    +        loff_t *ppos);
    +
    +extern unsigned int sysctl_sched_tty_sched_enabled;
    +
    +void tty_sched_create_group(struct tty_struct *tty);
    +void tty_sched_destroy_group(struct tty_struct *tty);
    +#else
    +static inline void tty_sched_create_group(struct tty_struct *tty) { }
    +static inline void tty_sched_destroy_group(struct tty_struct *tty) { }
    +#endif
    +
     #ifdef CONFIG_RT_MUTEXES
     extern int rt_mutex_getprio(struct task_struct *p);
     extern void rt_mutex_setprio(struct task_struct *p, int prio);
    Index: linux-2.6.36.git/include/linux/tty.h
    ===================================================================
    --- linux-2.6.36.git.orig/include/linux/tty.h
    +++ linux-2.6.36.git/include/linux/tty.h
    @@ -327,6 +327,9 @@ struct tty_struct {
         /* If the tty has a pending do_SAK, queue it here - akpm */
         struct work_struct SAK_work;
         struct tty_port *port;
    +#ifdef CONFIG_SCHED_DESKTOP
    +    struct task_group *tg;
    +#endif
     };
     
     /* Each of a tty's open files has private_data pointing to tty_file_private */
    Index: linux-2.6.36.git/kernel/sched.c
    ===================================================================
    --- linux-2.6.36.git.orig/kernel/sched.c
    +++ linux-2.6.36.git/kernel/sched.c
    @@ -78,6 +78,7 @@
     
     #include "sched_cpupri.h"
     #include "workqueue_sched.h"
    +#include "sched_tty.h"
     
     #define CREATE_TRACE_POINTS
     #include <trace/events/sched.h>
    @@ -612,11 +613,16 @@ static inline int cpu_of(struct rq *rq)
      */
     static inline struct task_group *task_group(struct task_struct *p)
     {
    +    struct task_group *tg;
         struct cgroup_subsys_state *css;
     
         css = task_subsys_state_check(p, cpu_cgroup_subsys_id,
                 lockdep_is_held(&task_rq(p)->lock));
    -    return container_of(css, struct task_group, css);
    +    tg = container_of(css, struct task_group, css);
    +
    +    tty_sched_check_attach(p, &tg);
    +
    +    return tg;
     }
     
     /* Change a task's cfs_rq and parent entity if it moves across CPUs/groups */
    @@ -1920,6 +1926,7 @@ static void deactivate_task(struct rq *r
     #include "sched_idletask.c"
     #include "sched_fair.c"
     #include "sched_rt.c"
    +#include "sched_tty.c"
     #ifdef CONFIG_SCHED_DEBUG
     # include "sched_debug.c"
     #endif
    Index: linux-2.6.36.git/drivers/char/tty_io.c
    ===================================================================
    --- linux-2.6.36.git.orig/drivers/char/tty_io.c
    +++ linux-2.6.36.git/drivers/char/tty_io.c
    @@ -185,6 +185,7 @@ void free_tty_struct(struct tty_struct *
     {
         kfree(tty->write_buf);
         tty_buffer_free_all(tty);
    +    tty_sched_destroy_group(tty);
         kfree(tty);
     }
     
    @@ -2823,6 +2824,7 @@ void initialize_tty_struct(struct tty_st
         tty->ops = driver->ops;
         tty->index = idx;
         tty_line_name(driver, idx, tty->name);
    +    tty_sched_create_group(tty);
     }
     
     /**
    Index: linux-2.6.36.git/kernel/sched_tty.h
    ===================================================================
    --- /dev/null
    +++ linux-2.6.36.git/kernel/sched_tty.h
    @@ -0,0 +1,7 @@
    +#ifdef CONFIG_SCHED_DESKTOP
    +static inline void
    +tty_sched_check_attach(struct task_struct *p, struct task_group **tg);
    +#else
    +static inline void
    +tty_sched_check_attach(struct task_struct *p, struct task_group **tg) { }
    +#endif
    Index: linux-2.6.36.git/kernel/sched_tty.c
    ===================================================================
    --- /dev/null
    +++ linux-2.6.36.git/kernel/sched_tty.c
    @@ -0,0 +1,128 @@
    +#ifdef CONFIG_SCHED_DESKTOP
    +#include <linux/tty.h>
    +
    +unsigned int __read_mostly sysctl_sched_tty_sched_enabled = 1;
    +
    +void tty_sched_create_group(struct tty_struct *tty)
    +{
    +    tty->tg = sched_create_group(&init_task_group);
    +    if (IS_ERR(tty->tg)) {
    +        tty->tg = &init_task_group;
    +         WARN_ON(1);
    +    }
    +}
    +EXPORT_SYMBOL(tty_sched_create_group);
    +
    +void tty_sched_destroy_group(struct tty_struct *tty)
    +{
    +    if (tty->tg && tty->tg != &init_task_group)
    +        sched_destroy_group(tty->tg);
    +}
    +EXPORT_SYMBOL(tty_sched_destroy_group);
    +
    +static inline void
    +tty_sched_check_attach(struct task_struct *p, struct task_group **tg)
    +{
    +    struct tty_struct *tty;
    +    int attach = 0, enabled = sysctl_sched_tty_sched_enabled;
    +
    +    rcu_read_lock();
    +    tty = p->signal->tty;
    +    if (!tty)
    +        goto out_unlock;
    +
    +    if (enabled && *tg == &root_task_group) {
    +        *tg = p->signal->tty->tg;
    +        attach = 1;
    +    } else if (!enabled && *tg == tty->tg) {
    +        *tg = &root_task_group;
    +        attach = 1;
    +    }
    +
    +    if (attach && !p->se.on_rq) {
    +        p->se.vruntime -= cfs_rq_of(&p->se)->min_vruntime;
    +        p->se.vruntime += (*tg)->cfs_rq[task_cpu(p)]->min_vruntime;
    +    }
    +
    +out_unlock:
    +    rcu_read_unlock();
    +}
    +
    +void tty_sched_move_task(struct task_struct *p, struct task_group *tg)
    +{
    +    struct sched_entity *se = &p->se;
    +    struct rq *rq;
    +    unsigned long flags;
    +    int on_rq, running, cpu;
    +
    +    rq = task_rq_lock(p, &flags);
    +
    +    running = task_current(rq, p);
    +    on_rq = se->on_rq;
    +    cpu = rq->cpu;
    +
    +    if (on_rq)
    +        dequeue_task(rq, p, 0);
    +    if (unlikely(running))
    +        p->sched_class->put_prev_task(rq, p);
    +
    +    if (!on_rq)
    +        se->vruntime -= cfs_rq_of(se)->min_vruntime;
    +
    +    se->cfs_rq = tg->cfs_rq[cpu];
    +    se->parent = tg->se[cpu];
    +
    +    p->rt.rt_rq  = tg->rt_rq[cpu];
    +    p->rt.parent = tg->rt_se[cpu];
    +
    +    if (!on_rq)
    +        se->vruntime += cfs_rq_of(se)->min_vruntime;
    +
    +    if (unlikely(running))
    +        p->sched_class->set_curr_task(rq);
    +    if (on_rq)
    +        enqueue_task(rq, p, 0);
    +
    +    task_rq_unlock(rq, &flags);
    +}
    +
    +int sched_tty_sched_handler(struct ctl_table *table, int write,
    +        void __user *buffer, size_t *lenp,
    +        loff_t *ppos)
    +{
    +    struct task_struct *p, *t;
    +    struct task_group *tg;
    +    unsigned long flags;
    +    int ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
    +
    +    if (ret || !write)
    +        return ret;
    +
    +    read_lock_irqsave(&tasklist_lock, flags);
    +
    +    rcu_read_lock();
    +    for_each_process(p) {
    +        tg = task_group(p);
    +        tty_sched_move_task(p, tg);
    +        list_for_each_entry_rcu(t, &p->thread_group, thread_group) {
    +            tty_sched_move_task(t, tg);
    +        }
    +    }
    +    rcu_read_unlock();
    +
    +    read_unlock_irqrestore(&tasklist_lock, flags);
    +
    +    return 0;
    +}
    +
    +static int __init setup_tty_sched(char *str)
    +{
    +    unsigned long val;
    +
    +    val = simple_strtoul(str, NULL, 0);
    +    sysctl_sched_tty_sched_enabled = val ? 1 : 0;
    +
    +    return 1;
    +}
    +__setup("ttysched=", setup_tty_sched);
    +#endif
    Index: linux-2.6.36.git/kernel/sysctl.c
    ===================================================================
    --- linux-2.6.36.git.orig/kernel/sysctl.c
    +++ linux-2.6.36.git/kernel/sysctl.c
    @@ -384,6 +384,17 @@ static struct ctl_table kern_table[] = {
             .mode        = 0644,
             .proc_handler    = proc_dointvec,
         },
    +#ifdef CONFIG_SCHED_DESKTOP
    +    {
    +        .procname    = "sched_tty_sched_enabled",
    +        .data        = &sysctl_sched_tty_sched_enabled,
    +        .maxlen        = sizeof(unsigned int),
    +        .mode        = 0644,
    +        .proc_handler    = sched_tty_sched_handler,
    +        .extra1        = &zero,
    +        .extra2        = &one,
    +    },
    +#endif
     #ifdef CONFIG_PROVE_LOCKING
         {
             .procname    = "prove_locking",
    Index: linux-2.6.36.git/init/Kconfig
    ===================================================================
    --- linux-2.6.36.git.orig/init/Kconfig
    +++ linux-2.6.36.git/init/Kconfig
    @@ -652,6 +652,19 @@ config DEBUG_BLK_CGROUP
     
     endif # CGROUPS
     
    +config SCHED_DESKTOP
    +    bool "Desktop centric group scheduling"
    +    depends on EXPERIMENTAL
    +    select CGROUPS
    +    select CGROUP_SCHED
    +    select FAIR_GROUP_SCHED
    +    select RT_GROUP_SCHED
    +    select BLK_CGROUP
    +    help
    +      This option optimizes the group scheduler for common desktop workloads,
    +      by creating separate per tty groups. This separation of workloads isolates
    +      aggressive CPU burners (like build jobs) from desktop applications.
    +
     config MM_OWNER
         bool
    If this is bulletin sheet, then we need to know.

    Thank You,
    My Blog: https://forums.opensuse.org/blogs/jdmcdaniel3/

    Software efficiency halves every 18 months, thus compensating for Moore's Law

    Its James again from Austin, Texas

  8. #8
    Join Date
    Jun 2008
    Location
    Kansas City Area, Missouri, USA
    Posts
    7,381

    Default Re: New Kernel Speed up Patch File from Mike Galbraith?

    On 11/19/2010 04:36 PM, jdmcdaniel3 wrote:
    >
    > I found this which was reported to be the speed up patch, but I surely
    > could be wrong. If one had the source code for a kernel, how would this
    > patch be applied for testing.


    It can only be applied if you have a 2.6.37-rcX kernel. Then you use the usual
    patch mechanism. If that does not mean anything to you, then you probably do not
    have the skills necessary.

    The patch does not speed up the kernel. A batch job that takes 2 hours, will
    still take close to 2 hours. What it does is improve the responsiveness of the
    kernel by modifying the scheduler. Interactive jobs will be affected the most.

  9. #9
    Join Date
    Mar 2010
    Location
    Austin - Texas
    Posts
    10,500
    Blog Entries
    48

    Smile Re: New Kernel Speed up Patch File from Mike Galbraith?

    It can only be applied if you have a 2.6.37-rcX kernel. Then you use the usual
    patch mechanism. If that does not mean anything to you, then you probably do not
    have the skills necessary.
    Yes, I guess you are right. Only people born with the knowledge should be compiling kernels with patches.

    Thank You,
    My Blog: https://forums.opensuse.org/blogs/jdmcdaniel3/

    Software efficiency halves every 18 months, thus compensating for Moore's Law

    Its James again from Austin, Texas

  10. #10
    Join Date
    Jun 2008
    Location
    Kansas City Area, Missouri, USA
    Posts
    7,381

    Default Re: New Kernel Speed up Patch File from Mike Galbraith?

    On 11/19/2010 10:06 PM, jdmcdaniel3 wrote:
    >
    >> It can only be applied if you have a 2.6.37-rcX kernel. Then you use the
    >> usual
    >> patch mechanism. If that does not mean anything to you, then you
    >> probably do not
    >> have the skills necessary.Yes, I guess you are right. Only people born with the knowledge should

    > be compiling kernels with patches.


    You don't need to be born with that knowledge. In fact, computers had not yet
    been invented when I was born, but I have worked very hard since 1995 in
    building kernels for special purposes, and since 2000 in debugging kernels and
    drivers. It does require some effort to learn, and when I see a question like
    yours, it is clear that you are not quite ready. To answer your question, one
    would use the "patch" utility. One thing, patch is finicky, and one does need to
    know how to recover when it fails.

Page 1 of 7 123 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •