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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #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


                  and the second benchmark


                  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; 20 June 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

                    Working...
                    X