Page 1 of 15 12311 ... LastLast
Results 1 to 10 of 150

Thread: RIFS-ES Linux Kernel Scheduler Released

  1. #1
    Join Date
    Jan 2007
    Posts
    15,628

    Default 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. #2
    Join Date
    May 2012
    Location
    GuangDong,China
    Posts
    141

    Default

    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.

  3. #3
    Join Date
    Dec 2008
    Posts
    151

    Default

    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.

  4. #4
    Join Date
    Dec 2009
    Posts
    29

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

  5. #5
    Join Date
    Dec 2011
    Posts
    2,193

    Default Graphs

    This article is useless without graphs.

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

  6. #6
    Join Date
    May 2012
    Location
    GuangDong,China
    Posts
    141

    Default

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

  7. #7
    Join Date
    Jun 2011
    Posts
    57

    Default

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

  8. #8
    Join Date
    Oct 2011
    Posts
    56

    Default 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?

  9. #9
    Join Date
    May 2012
    Location
    GuangDong,China
    Posts
    141

    Default

    Quote 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 at 01:10 PM.

  10. #10
    Join Date
    Oct 2011
    Posts
    56

    Default

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •