Friday, September 8, 2017

VRQ 0.97b release

VRQ 0.97b is released with the following changes

1. Select a random rq when no preemptible rq available. This will help with removing the bottleneck when cpu number increased.
2. Add rr_interval kernel parameter. Now an "rr_interval=" kernel parameter is added, but it's not suggested to change the default rr_interval setting(6ms).
3. Introduce sched_prio_to_deadline[NICE_WIDTH] to simplify deadline calculation.
4. Extend NORMAL policy level to 7 levels, this change help with reducing rq look up cost when cpu number increased. And it also brings deadline fairness for different nice level NORMAL policy tasks. eg, when two nice 19 background tasks runs with 2 nice 0 front-ground tasks in a two cpus system, those two background tasks may both be on same cpu while normal tasks occupied another. In previous release, as a workaround for this use case, the background tasks need to be IDLE policy to trigger the policy fairness balance functionality. With this new changes, there is 7 NORMAL policy levels according to task's deadline, so the nice 19 background tasks(which likely have large virtual deadline) also can be triggered for the policy fairness balance functionality.

The main features for 0.97? release has been all set now for 4.13 kernel, these feature code has been running on my machines for 2week+, so they are consider stable. In next release, the major change will be renaming and documentation.

Enjoy VRQ 0.97a for v4.13 kernel, :)

code are available at
https://bitbucket.org/alfredchen/linux-gc/commits/branch/linux-4.13.y-vrq
and also
https://github.com/cchalpha/linux-gc/commits/linux-4.13.y-vrq

All-in-one patch is available too.

13 comments:

  1. Compiles/boots okay, also passes smoke test.

    ReplyDelete
    Replies
    1. @Alfred:
      I kept quiet, as I haven't seen any related issue during the last ~3 days since compilation. Thank you for your valuable work!

      @Oleksandr:
      I also want to thank you very much in this place for closely tracking the BFQ I/O scheduler changes within your PF kernels/ your github repo!

      BR, Manuel Krause

      Delete
    2. @Manuel
      No news == good news. I can consider this release is stable. As no need to work on emergency fix, I can settle down and work on the renaming task and some minor adjustment.
      Enjoy it, :)

      Delete
  2. Thanks Alfred; x64 built fine, i686 fails:
    https://gist.github.com/jeremywh7/ebf1438949e9f715eada3b7c8e4ce5b8

    ReplyDelete
    Replies
    1. @jwh7
      Thanks for reporting. It's UP compilation issue again. I have pushed a fix at
      https://bitbucket.org/alfredchen/linux-gc/commits/2894c6609a5f37c9b7c5fc28271e959891a6eb2b

      Delete
    2. Applied, built, and now running; thanks again!

      Delete
  3. Compiled fine here on Ryzen, I installed it on Ryzen, i7 and Phenom.
    I played Doom 2016, Diablo3, WOT and compiled stuff on Ryzen, played Rocket League on Phenom, wrote a comment in this page on i7, it seems totally fine, no issues so far :)

    I noticed 5-7% FPS improvement in Diablo3, can it so that there is a performance improvement in this release? Doom or WOT did not show any easily measurable FPS increase, tho.

    Thanks Alfred,
    Eduardo & Rinaldo

    ReplyDelete
    Replies
    1. @Edurado
      Yes, based on my kernel compilation benchmark, there is improvement in all kinds of workload, at least no regression compare to previous release.

      Delete
  4. I'm getting a kernel warning:
    https://paste.ubuntu.com/25539058/
    System is running with threadirqs cpu is a i7-5960X

    ReplyDelete
    Replies
    1. Any system hang or unexpected behaviors after this warning message?
      This warning is added to help to find out an expected scenario, and it works when developing recent code changes. So it is kept there.

      Delete
    2. No, everything is ok just wanted to report it.

      Delete
    3. That should be a rare normal scenario also trigger this warning. Can it be reproduced and would you like to apply a debug patch print out more useful info about what happened?

      Delete
    4. I think I have found that "rare" scenario(calling sys_sched_yield), will wokr on a solution to fix it. Thanks for reporting.

      Delete