Wednesday, August 2, 2017

VRQ 0.96f release

VRQ 0.96f is released with the following changes

1. Improvement for smt sensitive scheduling.
2. No dequeue/enqueue for task on cpu.
3. Code clean up.


#2 is the major change in this release, unlike the previous version, now when task is going to be run on a cpu, there is no need to dequeue the task from the run queue skip list, enqueue/dequeue will only happen when task become runnable/unrunnable. With this change, the overhead of enqueue/dequeue is significantly reduced, and the logic of scheduler is more simple.

And please also be noticed, to adapt to this new enqueu/dequeue strategy, some important code path has been rewriten. You may experience unstable issues with this release. (So far, none for me at least)

Enjoy VRQ 0.96f for v4.12 kernel, :)

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

All-in-one patch is available too.

15 comments:

  1. It survived my smoke tests, so should be OK :).

    Thanks.

    ReplyDelete
  2. Hey Alfred,
    x64 built fine, but x86 fails with:
    https://gist.github.com/jeremywh7/ee8a36b7cc580bbf7a9e2650d19b2e81

    ReplyDelete
    Replies
    1. I assume this happens because of CONFIG_SMP=n, correct?

      Delete
    2. Yes. It's SMP related, I am working on fix commit. Just waiting it to pass the SMP=N compilation before pushing it to git.

      Delete
    3. @jwh7
      Thanks for reporting. I have pushed a fix commit to git, you can check it out at
      https://bitbucket.org/alfredchen/linux-gc/commits/4372c4f37a7d200184d4f13657911e850b312c95

      github also be updated.

      Delete
    4. Thanks Alfred; x86 (no SMP) builds fine now. :)

      Delete
  3. Thanks Alfred.
    My usual benchmarks completed without problems.

    Pedro

    ReplyDelete
    Replies
    1. @Pedro
      I saw your updated benchmarks. Although VRQ096f 1000Hz got two worst but from the value respect, it doesn't different that much. And I'd love to see -j4 compilation result, 10%, that really shows what smt sensitive scheduling feature does. The overall result of VRQ096f 1000Hz also looks good. Thanks for your effects of benchmarking, I have similar benchmark records, but it is more convincing when it comes from a 3rd party.

      I will continue looking into any improvement can be made for 100% and 150% workload in the incoming release.

      Delete
  4. @Alfred:
    This seems to me to be a great piece of rework.
    With the previous revision I've seen left/right stereo audio switching problems, but was not sure about the reason, it's gone. Also, the earlier mentioned WARNING:
    -->
    workqueue: PF_MEMALLOC task 8676(systemd-sleep) is flushing !WQ_MEM_RECLAIM i915:i915_gem_idle_work_handler [i915]
    [ 8982.750618] ------------[ cut here ]------------
    [ 8982.750623] WARNING: CPU: 0 PID: 8676 at kernel/workqueue.c:2418 check_flush_dependency+0x7a/0xfd
    <--
    is gone now (full trace snippet here: https://pastebin.com/h2DYrUwf).

    Unfortunately I'm back in testing TOI, and don't want to interrupt the current testing row until it fails first time, to do cross checks with the three changes I've made to the currently running kernel. Is it possible that your actual changes made the issue go away?

    Thank you for your work and BR,
    Manuel Krause

    ReplyDelete
    Replies
    1. @Manuel
      If you talking about the changes of enqueue/dequeue, those are most scheduler internal related.
      Good luck with your TOI testing.

      Delete
    2. @Alfred:
      Yes, I thought of the enqueue/dequeue thing mainly, the other commits are unlikely to have effect on here (due to SMT dependency).
      Regarding the TOI testing (thanks for your wishes!) I got up to 8 successful resumes in a row, remarkable, then facing a BUG with it, and No.9 failed to resume. I don't think it's related to VRQ, but have uploaded the trace, so you maybe comment if I'm right: https://pastebin.com/h9gjzcTi

      Atm. I need to re-check whether I have all needed fixes for BFQ i/o scheduler in place, for which post-factum made a nice summary here:
      https://groups.google.com/forum/?fromgroups=#!topic/bfq-iosched/1zoZu00b-C0
      on Aug. 5th, before I proceed.
      BTW, great thanks for your work, too, Oleksandr!

      Best regards,
      Manuel

      Delete
    3. Shame on me -- I really missed at least two early fix commits that appear really important.
      Recompiling, then restarting the hibernation tests... BR, Manuel

      Delete
  5. I've used both ck and your patch when it was at v0.95 and both suffered similar inversion issues with wine and I wasn't sure how to debug it at the time.

    A lot of time has passed, so I patched the new v0.96f and got netconsole ready; but saw absolutely no issues at all. I am very surprised how stable and responsive it is. Really amazing work!

    I will continue testing to see if I run into any bugs and races.

    ReplyDelete
    Replies
    1. @Tom
      Yes. Thanks for all who join the testing and feedback in recent releases. Now VRQ is more reliable than it used to be.
      If the inversion issues you talk about is related to rtmutex or task priority boost, I happened to write a VRQ adaption for deadline in rtmutex last weekend and will be included in next release.

      Delete
  6. Hi,

    works fine on i7 for 3 days, multiple suspends in between and on Ryzen, for couple of days. Did not do any specific testing, but so far so good.
    Also, I compile kernel now w/ 250Hz and NO_HZ_IDLE, that works very good for gaming on old Phenom II as well.

    Thanks Alfred,
    Br, Eduardo

    ReplyDelete