Announcement

Collapse
No announcement yet.

RIFS-ES Linux Kernel Scheduler Released

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

  • #21
    Originally posted by ulenrich View Post
    I am publishing my esperience here:


    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; 21 June 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; 21 June 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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