Announcement

Collapse
No announcement yet.

RIFS-ES Linux Kernel Scheduler Released

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

  • RIFS-ES Linux Kernel Scheduler Released

    Phoronix: RIFS-ES Linux Kernel Scheduler Released

    RIFS-ES V1 has been published as a new interactivity favor scheduler for the Linux kernel...

    http://www.phoronix.com/vr.php?view=MTEyMjg

  • #2
    I am the second one.

    If a task sleep and wake up very often it can still gain high priority but the priority will be lower than some task like:
    int main()
    {
    int i;
    for(i = 0;i < 60;i++)
    sleep(1);
    }

    These(ES feature) ideas are got from System V scheduler. I improve them and bind them with RIFS.
    They are actually a very good solution for desktop. I improve them to make sure that these idea can make a better responaive for the task which needs as small latency as they can.

    Comment


    • #3
      For interactivity, it seems to me that the maximum latencies are much more important than the average. And there does not seem to be a clear improvement over CFS maximum latencies in the benchmarks in the email.

      Comment


      • #4
        Looks promising

        The average latency seems way better than CFS, and it even beats BFS at high client counts.

        What I'm curious is if the throughput gets killed.

        On the other hand, BFS seems to do just as well for low client counts, and has already been debugged far more than this.

        Good luck to the developer!

        Now if we could only finally resurrect the plugable scheduler system for the kernel.

        Comment


        • #5
          Graphs

          This article is useless without graphs.

          Benchmark CFS, BFS, RIFS-ES and do graph.

          Comment


          • #6
            Originally posted by hechacker1 View Post
            The average latency seems way better than CFS, and it even beats BFS at high client counts.

            What I'm curious is if the throughput gets killed.

            On the other hand, BFS seems to do just as well for low client counts, and has already been debugged far more than this.

            Good luck to the developer!

            Now if we could only finally resurrect the plugable scheduler system for the kernel.
            plugable scheduler is a comfortable thing
            BFS uses real-time scheduling algorithm so with low client counts it can give O(1) lag bound but with higher amount of client count many task will miss the deadline and it is not O(1) lag anymore.

            Comment


            • #7
              Originally posted by uid313 View Post
              This article is useless without graphs.

              Benchmark CFS, BFS, RIFS-ES and do graph.
              A graph comparing BFS and RIFS-ES will probably be helpful since they're about latency for desktops, but comparing CFS isn't going to help because it's all about throughput.

              Plus, comparing BFS and RIFS-ES is going to be tough to quantify. How can you make a chart quantifying the desktop experience with BFS against RIFS-ES? Someone's probably going to have to buy an eight-year old desktop and just eyeball the performance and tell the internet what s/he thinks.

              Comment


              • #8
                funny statistic pic

                going up from
                60 to 200 clients
                you will have latency going from
                50000 down to 5000

                This is funny!
                Is this a quantum machine running faster on high loads?

                Comment


                • #9
                  Originally posted by ulenrich View Post
                  going up from
                  60 to 200 clients
                  you will have latency going from
                  50000 down to 5000

                  This is funny!
                  Is this a quantum machine running faster on high loads?
                  This is the new version
                  https://rifs-scheduler.googlecode.co...ec-kernel3.4.x

                  and the second benchmark
                  https://rifs-scheduler.googlecode.co...Result-002.PNG

                  Text version
                  #MONTH *CFS * * RIFS-ES(new) BFS
                  1 * * * 21 * * *8 * * * * * * * 7
                  2 * * * 19 * * *8 * * * * * * * 7
                  4 * * * 4678 * *1402 * * * * * *2625
                  8 * * * 9111 * *4361 * * * * * *5271
                  16 * * *17944 * 7589 * * * * * *12611
                  32 * * *35628 * 21864 * * * * * 25381
                  64 * * *69205 * 43145 * * * * * 51653
                  128 * * 93522 * 35553 * * * * * 97354
                  255 * * 134560 *6288 * * * * * *200071

                  Edit 2
                  The new version has fixed one build issue on NON-SMP processors
                  And sleep-tracking is disabled.

                  Edit 3
                  I have to mention one more time.
                  The algorithm used in BFS is EEVDF Variation
                  EEVDF is designed for real-time environment
                  The good point I have mention already is that wich low workload EEVDF can provide O(1) lag. However with bigger load the lag bound is not O(1) anymore.
                  Last edited by 3766691; 06-20-2012, 12:10 PM.

                  Comment


                  • #10
                    Chen your graphic Result-002.PNG
                    looks logical regarding the BFS and CFS curves:
                    BFS going higher at some point, but better performance at first.

                    But your RIFS curve is just funny:
                    The higher the load the better the performance.
                    Or is the RIFS curve a kind of integration level two: a kind of difference to CFS

                    Comment


                    • #11
                      Another idea regarding your statistic:
                      It is not meant to show the latency of the overall system, but the performance of a single function ordering the loads compared?
                      (the logN efficiency you mentioned erlier)

                      Comment


                      • #12
                        Originally posted by ulenrich View Post
                        Another idea regarding your statistic:
                        It is not meant to show the latency of the overall system, but the performance of a single function ordering the loads compared?
                        (the logN efficiency you mentioned erlier)
                        It shows the latency of 'sleep 10'

                        Comment


                        • #13
                          Originally posted by ulenrich View Post
                          going up from
                          60 to 200 clients
                          you will have latency going from
                          50000 down to 5000

                          This is funny!
                          Is this a quantum machine running faster on high loads?
                          Yes, this is very weird.
                          I don't think this is possible.
                          Why the graph look like this?

                          Comment


                          • #14
                            Originally posted by uid313 View Post
                            Yes, this is very weird.
                            I don't think this is possible.
                            Why the graph look like this?
                            Hi

                            Here is a newer benchmark around latt -c255 sleep 10 between these 3 cpu scheduler.
                            http://code.google.com/p/rifs-schedu...Result-003.PNG

                            RIFS-ES-Low-Spec has been posted, if you want a link please click the follow site.
                            http://rifs-scheduler.googlecode.com...ec-kernel3.4.x

                            After using it if you think it is useful please invite the others to use it.
                            Thanks

                            Chen

                            EDIT 2

                            All right I am going to make a conclusion for the benchmark
                            Although BFS get the worst average latency but it also get the best max_latency value.
                            Last edited by 3766691; 06-21-2012, 06:10 AM.

                            Comment


                            • #15
                              Originally posted by 3766691 View Post
                              Hi

                              Here is a newer benchmark around latt -c255 sleep 10 between these 3 cpu scheduler.
                              http://code.google.com/p/rifs-schedu...Result-003.PNG
                              Looks very weird.
                              The latency jumps up and down unpredictably instead of scaling smoothly.

                              Comment

                              Working...
                              X