Announcement

Collapse
No announcement yet.

RIFS-ES Linux Kernel Scheduler Released

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

  • #16
    Originally posted by uid313 View Post
    Looks very weird.
    The latency jumps up and down unpredictably instead of scaling smoothly.
    Even it jumps up and down it is still lower than the other 2 scheduler.
    During the test I will move the mouse(I just move the mouse and I don't click anything).
    With BFS the mouse stalls.
    With CFS or RIFS-ES-Low-Spec the mouse is very smooth.

    With average latency RIFS wins, with maximum latency BFS wins.
    Chen

    Comment


    • #17
      smooth! well done Chen!

      I just run a linux-3.4.4rc using the additional patch
      RIFS.ES-v1-low-spec-kernel3.4.x

      No issues with audio as was before!
      Very smooth experience with high load
      compile + flash + video
      all at the same time!

      Thank you very mush Chen!

      The BFS alternative will have issues with the newest linux-3.4.4
      regarding a rpc patch as I pointed to at Kon Colivas blog.

      Comment


      • #18
        Originally posted by ulenrich View Post
        I just run a linux-3.4.4rc using the additional patch
        RIFS.ES-v1-low-spec-kernel3.4.x

        No issues with audio as was before!
        Very smooth experience with high load
        compile + flash + video
        all at the same time!

        Thank you very mush Chen!

        The BFS alternative will have issues with the newest linux-3.4.4
        regarding a rpc patch as I pointed to at Kon Colivas blog.
        Thanks for trying.
        If the mainline can make CFS smooth then RIFS will stop publishing.
        The existance of RIFS is to make the kernel smooth.
        If you want you can invite the other to us it, or you can hack the scheduler and post your hacking.

        We have to let the maintainer to know that they should improve the desktop user experience now.

        Chen

        Comment


        • #19
          Originally posted by 3766691 View Post
          Thanks for trying.
          If the mainline can make CFS smooth then RIFS will stop publishing.
          The existance of RIFS is to make the kernel smooth.
          If you want you can invite the other to us it, or you can hack the scheduler and post your hacking.

          We have to let the maintainer to know that they should improve the desktop user experience now.

          Chen
          I have made an decision that I will still continue maintaining and developing it even after the mainline has improved the interactive

          Comment


          • #20
            I am publishing my esperience here:
            http://siduction.org/index.php?name=...93b39deb#21450

            Siduction is an effective an little community around Debian unstable. Towo, the kernel guy there, had applied BFS patches for Linux-3.2 back then. But you dont have to use it to discuss in the forums. My main distribution yet is Gentoo, which is not only a "rollin' release" but a rolling MYrelease.

            Comment


            • #21
              Originally posted by ulenrich View Post
              I am publishing my esperience here:
              http://siduction.org/index.php?name=...93b39deb#21450

              Siduction is an effective an little community around Debian unstable. Towo, the kernel guy there, had applied BFS patches for Linux-3.2 back then. But you dont have to use it to discuss in the forums. My main distribution yet is Gentoo, which is not only a "rollin' release" but a rolling MYrelease.
              The original version of RIFS-ES is broken with design already. Seems many people like RIFS-ES-Low-Spec so in 3.5 kernel it will be the offical one. RIFS V2 will still be updated to make a compairsion between RIFS and RIFS-ES

              Sometimes we want to avoid somethings by some little tricky design, but almostly the one which has no tricky design is the best.
              In LKML I have mention that the tricky design has destroyed CFS. One more things I have to mention is, the time complexity of RIFS and RIFS-ES-LOW-SPEC is O(1)
              Last edited by 3766691; 06-21-2012, 11:36 AM.

              Comment


              • #22
                Chen
                it is the time some one comes up (again), to try to convince mainline of a
                compile time plugin source structure regarding schedulers!

                All needed to alter the scheduler should be only at
                linux/kernel/sched/cfs/
                linux/kernel/sched/rifs/
                linux/kernel/sched/bfs/
                linux/kernel/sched/my/
                one place,
                no more patching necessary of all these
                +++ linux-3.4.1-RIFS/fs/proc/base.c
                +++ linux-3.4.1-RIFS/include/linux/init_task.h
                +++ linux-3.4.1-RIFS/kernel/delayacct.c
                +++ linux-3.4.1-RIFS/kernel/exit.c
                +++ linux-3.4.1-RIFS/kernel/posix-cpu-timers.c
                +++ linux-3.4.1-RIFS/kernel/sysctl.c

                Comment


                • #23
                  Originally posted by ulenrich View Post
                  Chen
                  it is the time some one comes up (again), to try to convince mainline of a
                  compile time plugin source structure regarding schedulers!

                  All needed to alter the scheduler should be only at
                  linux/kernel/sched/cfs/
                  linux/kernel/sched/rifs/
                  linux/kernel/sched/bfs/
                  linux/kernel/sched/my/
                  one place,
                  no more patching necessary of all these
                  +++ linux-3.4.1-RIFS/fs/proc/base.c
                  +++ linux-3.4.1-RIFS/include/linux/init_task.h
                  +++ linux-3.4.1-RIFS/kernel/delayacct.c
                  +++ linux-3.4.1-RIFS/kernel/exit.c
                  +++ linux-3.4.1-RIFS/kernel/posix-cpu-timers.c
                  +++ linux-3.4.1-RIFS/kernel/sysctl.c
                  The patching for these 5 place is because CFS haa been hard-coded to the hole kernel. So we need to modify them.
                  init_task.h is used for filling the task_struct of init process, so modify it is needed.
                  It seems like that the kernel maintainer doesn't want us to develop our own scheduler.
                  Last edited by 3766691; 06-21-2012, 06:15 PM.

                  Comment


                  • #24
                    Originally posted by 3766691 View Post
                    The patching for these 5 place is because CFS haa been hard-coded to the hole kernel. So we need to modify them.
                    init_task.h is used for filling the task_struct of init process, so modify it is needed.
                    It seems like that the kernel maintainer doesn't want us to develop our own scheduler.
                    Let me mention more. The vanilla scheduler is now totally not for desktop and even the interactivity of Windows is better than vanilla(Though both of them sucks). Ralph, you can read the LKML message between me and Ingo:

                    On Wed, 2012-05-23 at 17:50 +0200, Ingo Molnar wrote:

                    > * Joe Perches <joe@perches.com> wrote:
                    > > In a 1000 cpu config, there also an extra 500+ bytes per cpu
                    > > in printk (I don't think that's particularly important btw)
                    > A 1000 cpu piece of hardware will have a terabyte of RAM or
                    > more. 0.5K per CPU is reasonable.


                    That's not fundamentally true, but it's not
                    particularly important right now either.

                    cheers, Joe
                    ===================

                    * Chen <hi3766691@gmail.com> wrote:

                    > Oh, Just count the size of the scheduler code yourself,
                    > actually 400 - 500k. core.c + fair.c + rt.c + idle_task.c +
                    > everything

                    Only binary code is counted in bytes, source code is counted in
                    lines.

                    20 KLOC for a full-featured CPU scheduler that does everything
                    from simple UP scheduling to thousands of CPUs NUMA scheduling,
                    cgroups, real-time and more, is entirely reasonable.

                    As a comparison the VM is 80+ KLOCS, arch/x86/ is 260+ KLOCs,
                    networking is 720+ KLOCS and the FS subsystem is over 1 million
                    lines of code.

                    The scheduler is in fact one of the smaller subsystems.

                    Thanks,

                    Ingo
                    ================

                    * Chen <hi3766691@gmail.com> wrote:

                    > Oh, Just count the size of the scheduler code yourself,
                    > actually 400 - 500k. core.c + fair.c + rt.c + idle_task.c +
                    > everything

                    Only binary code is counted in bytes, source code is counted in
                    lines.

                    20 KLOC for a full-featured CPU scheduler that does everything
                    from simple UP scheduling to thousands of CPUs NUMA scheduling,
                    cgroups, real-time and more, is entirely reasonable.

                    As a comparison the VM is 80+ KLOCS, arch/x86/ is 260+ KLOCs,
                    networking is 720+ KLOCS and the FS subsystem is over 1 million
                    lines of code.

                    The scheduler is in fact one of the smaller subsystems.

                    Thanks,

                    Ingo


                    He tries to compare the line of code between sched-subsystem, filesystem and even VM and said his code is not bloated and it is even a small subsystem.
                    BrainF*ck!!!

                    Comment


                    • #25
                      Chen,
                      that queer discussion just shows the importance of my point:
                      Seperate the scheduler code!

                      This seperation could serve a fresh start to improve the technique of the beating heart the scheduler!

                      Comment


                      • #26
                        Originally posted by ulenrich View Post
                        Chen,
                        that queer discussion just shows the importance of my point:
                        Seperate the scheduler code!

                        This seperation could serve a fresh start to improve the technique of the beating heart the scheduler!
                        It must be done someday and even now.
                        I am now trying to let RIFS-ES get into Gentoo source. Also I have finished the porting of 3.5.x kernel.

                        Comment


                        • #27
                          Originally posted by 3766691 View Post
                          Also I have finished the porting of 3.5.x kernel.
                          Would you please share the patch? Would love to test it.

                          Comment


                          • #28
                            Originally posted by TAXI View Post
                            Would you please share the patch? Would love to test it.
                            ++

                            I second that


                            will try it next week - by then additional fixes for btrfs probably will get in and the kernel should be pretty usable/stable

                            Comment


                            • #29
                              Originally posted by kernelOfTruth View Post
                              ++

                              I second that


                              will try it next week - by then additional fixes for btrfs probably will get in and the kernel should be pretty usable/stable
                              Wait I am playing LOL right now.

                              Comment


                              • #30
                                one sleepy thing

                                Chen,
                                could you look into the sleepy thingy once more?
                                I recently had a little annoyance with my wlan, this happened two times :
                                - doing something not internet related (watching soccer dvb-t using kaffeine) longer than an hour
                                - lost my wlan internet connection
                                The same happened directly after this a second time the same conditions.

                                Why I think it is RIFS related: On Gentoo, normaly loosing connection it is sufficient to
                                rc-service dhcpcd restart

                                But I had to do:
                                rc-service dhcpcd stop
                                rc-service wpa_supplicant restart
                                rc-service dhcpcd start

                                Which indicates a more deeply my broadcom-sta-wl module involved ...

                                Comment

                                Working...
                                X