Announcement

Collapse
No announcement yet.

RIFS-ES Linux Kernel Scheduler Released

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

  • #46
    Originally posted by ulenrich View Post
    @kernelOfTruth,
    you could set the ticks from 1000hz down to 300hz, which will have 70percent of the energy savings of tickless.

    @Chen,
    aren't cgroups important for the coming systemd?
    If so, then the most important feature of a new coming version of RIFS !
    thanks - yes, I did in the past with CFS but that caused (if I remember correctly) less smooth/less reactive desktop for me

    so I bumped it up to 1000 Hz


    will try it with 300 Hz + RIFS-ES low-spec now + NOHZ disabled

    hopefully that works out well

    Comment


    • #47
      Originally posted by 3766691 View Post
      If you have time could you also test RIFS-V2-Bugfix2-kernel3.4.x:
      http://rifs-scheduler.googlecode.com...x2-kernel3.4.x
      Thanks. I can't test because I can't find the difference between them.
      Chen,
      could you give me a more detailed rationale, why
      - I should use an older branch of code
      - what is different in principle to RIFS-ES
      - I could have more success in testing than you yourself

      Comment


      • #48
        Originally posted by ulenrich View Post
        Chen,
        could you give me a more detailed rationale, why
        - I should use an older branch of code
        - what is different in principle to RIFS-ES
        - I could have more success in testing than you yourself
        1.I have to examine that what RIFS-ES really improved.
        2.-ES has different method to decide whether we should increase the priority of a sleeper.And these idea is from the clasaic Unix scheduler and I have enhanced it.
        4.I am the author of these 2 scheduler and my feeling might be a bit subjective.Also if the others have claimed that it is good , it will be more powerful than my words.

        Comment


        • #49
          You didnt answer what RIFS-v2 is about in more detail!

          I am not a big tester. I just have a good 'feeling':

          BFS feels a bit faster when low load (only video using kaffeine)
          RIFS-ES feels the same if low load or high load (compile + video)

          Comment


          • #50
            Originally posted by 3766691 View Post
            Please disable them. Yes desktop doesn't need these

            EDIT 2:
            Now I post a new one.
            I know that disabling them fixes the errors, I just wanted to tell you so you can fix it in source.

            But now I tried to compile it on a netbook with Intel Atom CPU:

            block/built-in.o: In function `__blk_complete_request':
            (.text+0x8345): undefined reference to `cpus_share_cache'

            This time I don't know how to fix it.

            //EDIT: Fixed by changing

            shared = cpus_share_cache(cpu, ccpu);
            to

            shared = true; // Hardcoded for HT, else: cpus_share_cache(cpu, ccpu);

            in block/blk-softirq.c
            This code is for HyperThreading CPUs only and may fail on dual (or more) core CPUs. Also I couldn't test it yet as the netbook is slow and I have to do a lot more before I'm able to reboot.
            Last edited by V10lator; 06-23-2012, 10:23 AM.

            Comment


            • #51
              Originally posted by ulenrich View Post
              You didnt answer what RIFS-v2 is about in more detail!

              I am not a big tester. I just have a good 'feeling':

              BFS feels a bit faster when low load (only video using kaffeine)
              RIFS-ES feels the same if low load or high load (compile + video)
              It is the original RIFS actually.

              Comment


              • #52
                Originally posted by ulenrich View Post
                Chen,
                could you give me a more detailed rationale, why
                - I should use an older branch of code
                - what is different in principle to RIFS-ES
                - I could have more success in testing than you yourself
                Originally posted by TAXI View Post
                I know that disabling them fixes the errors, I just wanted to tell you so you can fix it in source.

                But now I tried to compile it on a netbook with Intel Atom CPU:

                block/built-in.o: In function `__blk_complete_request':
                (.text+0x8345): undefined reference to `cpus_share_cache'

                This time I don't know how to fix it.

                //EDIT: Fixed by changing

                shared = cpus_share_cache(cpu, ccpu);
                to

                shared = true; // Hardcoded for HT, else: cpus_share_cache(cpu, ccpu);

                in block/blk-softirq.c
                This code is for HyperThreading CPUs only and may fail on dual (or more) core CPUs. Also I couldn't test it yet as the netbook is slow and I have to do a lot more before I'm able to reboot.
                Originally posted by kernelOfTruth View Post
                I DO care about tickless :P

                best compromise about interactivity, smoothness and energy savings

                otherwise I could also use the rt-kernel


                or aren't there that much energy savings with tickless enabled ?
                Here I copy a whole things from the prev thread.

                This is RIFS-V3-Test(Actually is V5) based on RIFS-V2
                It solved the interactivity problem RIFS-ES has.

                http://rifs-scheduler.googlecode.com...s-V2-V3-Test.c



                EDIT 2
                Wow, I have run the latt -c255 sleep 10 with music playing and browsing using firefox.
                No lag with Music and Screen.

                [admin@localhost ~]$ latt -c255 sleep 10

                Parameters: min_wait=100ms, max_wait=500ms, clients=255
                Entries logged: 765

                Wakeup averages
                -------------------------------------
                Max 148215 usec
                Avg 11210 usec
                Stdev 20550 usec
                Stdev mean 743 usec

                Work averages
                -------------------------------------
                Max 1210226 usec
                Avg 59141 usec
                Stdev 89912 usec
                Stdev mean 3251 usec


                Remember to rename it to rifs.c and replace it with the original one.
                Chen

                Comment


                • #53
                  Originally posted by 3766691 View Post
                  Here I copy a whole things from the prev thread.

                  This is RIFS-V3-Test(Actually is V5) based on RIFS-V2
                  It solved the interactivity problem RIFS-ES has.

                  http://rifs-scheduler.googlecode.com...s-V2-V3-Test.c



                  EDIT 2
                  Wow, I have run the latt -c255 sleep 10 with music playing and browsing using firefox.
                  No lag with Music and Screen.

                  [admin@localhost ~]$ latt -c255 sleep 10

                  Parameters: min_wait=100ms, max_wait=500ms, clients=255
                  Entries logged: 765

                  Wakeup averages
                  -------------------------------------
                  Max 148215 usec
                  Avg 11210 usec
                  Stdev 20550 usec
                  Stdev mean 743 usec

                  Work averages
                  -------------------------------------
                  Max 1210226 usec
                  Avg 59141 usec
                  Stdev 89912 usec
                  Stdev mean 3251 usec


                  Remember to rename it to rifs.c and replace it with the original one.
                  Chen
                  RIFS-V3-Test will not optmise for big workload anymore and it now focuses on fair. Also it should fix the building issue.

                  Although it will produce a bad latt benchmark result, it will produce good user experience.

                  @ulenrich @TAXI:
                  You can try whether it solves the building issue with some configuration or not.
                  Last edited by 3766691; 06-25-2012, 06:36 AM.

                  Comment


                  • #54
                    For interactivity, it seems to me that the maximum latencies are much more important than the average.

                    Comment


                    • #55
                      http://rifs-scheduler.googlecode.com/files/bfs.c

                      BFS-O(1)-423. Patch the kernel with BFS first.
                      It is an improvement patch on data structure. As you see, the time complexity of BFS is O(n) and with this the time complexity become O(1).

                      Comment


                      • #56
                        @3766691:

                        smecenter has a point - overall RIFS-ES is a very smooth and great scheduler

                        to make it the best it is paramount that the max latencies also get smaller


                        I'm currently still using it with 3.4.2 and it's working great but from time to time there are small noticable lags during heavy i/o (the same with BFS & CFS)

                        it's not RIFS-ES/the cpu scheduler's fault if the i/o or VFS subsystem, device-mapper, etc. etc. screw up and lead to delays but it would at least be nice if the cpu scheduler could manage to keep latencies to a minimum on its own


                        any ideas on how to improve it more ?

                        otherwise it's awesome


                        thanks !

                        Comment


                        • #57
                          Originally posted by kernelOfTruth View Post
                          @3766691:

                          smecenter has a point - overall RIFS-ES is a very smooth and great scheduler

                          to make it the best it is paramount that the max latencies also get smaller


                          I'm currently still using it with 3.4.2 and it's working great but from time to time there are small noticable lags during heavy i/o (the same with BFS & CFS)

                          it's not RIFS-ES/the cpu scheduler's fault if the i/o or VFS subsystem, device-mapper, etc. etc. screw up and lead to delays but it would at least be nice if the cpu scheduler could manage to keep latencies to a minimum on its own


                          any ideas on how to improve it more ?

                          otherwise it's awesome


                          thanks !
                          Heavy IO task always sleep with TASK_UNINTERRUPTIBLE. We can adjust the scheduler by this clue.
                          But still RIFS-v2 performs the best on your machine, isn't?
                          You may also see DMS SCHEDULER on the download page.

                          Comment


                          • #58
                            Originally posted by 3766691 View Post
                            Heavy IO task always sleep with TASK_UNINTERRUPTIBLE. We can adjust the scheduler by this clue.
                            But still RIFS-v2 performs the best on your machine, isn't?
                            You may also see DMS SCHEDULER on the download page.
                            ok, I see

                            making it TASK_UNINTERRUPTIBLE would probably solve the issue with input lag during heavy i/o - especially under the amd64 architecture (intel only ?) - once and for all


                            provided of course that all the i/o (especially writing) is marked TASK_UNINTERRUPTIBLE



                            yeah, it's the best scheduler so far

                            what does that DMS Scheduler exactly change ? from what I read it prioritizes user input somehow and is swap aware ? is that correct ?


                            will test that one asap


                            great work !

                            thanks

                            Comment


                            • #59
                              Originally posted by kernelOfTruth View Post
                              ok, I see

                              making it TASK_UNINTERRUPTIBLE would probably solve the issue with input lag during heavy i/o - especially under the amd64 architecture (intel only ?) - once and for all


                              provided of course that all the i/o (especially writing) is marked TASK_UNINTERRUPTIBLE



                              yeah, it's the best scheduler so far

                              what does that DMS Scheduler exactly change ? from what I read it prioritizes user input somehow and is swap aware ? is that correct ?


                              will test that one asap


                              great work !

                              thanks
                              DMS is a cpu scheduler.The algo. it used is proportional fair(EDF) with O(1) time complexity

                              Comment


                              • #60
                                Originally posted by 3766691 View Post
                                DMS is a cpu scheduler.The algo. it used is proportional fair(EDF) with O(1) time complexity
                                oh nice !

                                a fixed priority preemptive scheduling policy


                                I just tried it and the kernel hang during bringing up the CPUs so it must be an issue with the cpu scheduler

                                patched RIFS.ES-v1-low-spec-kernel3.4.x first and then replaced rifs.c with the one from "DMS-3.4.x V1(patch your kernel with RIFS-ES first)"


                                any ideas ?


                                thanks !

                                Comment

                                Working...
                                X