Wednesday, August 16, 2017

VRQ 0.97 released

VRQ 0.97 is released with the following changes

1. Fix UP compilation issue, reported by jwh7.
2. rtmutex deadline adaption for VRQ.
3. Overhead reduction in take_other_rq_task() and SMT code path in task_preemptible_rq().
4. Preparation for Normal policy level expansion feature.

Version bump up to 0.97 because smt sensitive scheduling, the main feature in 0.96 has finally been accomplished. In 0.97, normal policy level expansion and task deadline adjustment are the main features. In this release, just the preparation code of normal policy level expansion is included, the prototype code still under testing.

And, there will be no more release before 4.13 kernel come out.

Enjoy VRQ 0.97 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.
Posted by at
Labels: , , , , ,

16 comments:

  1. AnonymousAugust 17, 2017 at 12:37 PM

    My system works very well with VRQ 0.97.
    No difference noticed vs. former VRQ 0.96f. @Alfred, you need to decide whether it's good or bad news ;-)

    BR, Manuel Krause

    ReplyDelete
    Replies
    1. Alfred ChenAugust 17, 2017 at 5:19 PM

      @Manuel
      That's a good news, you wouldn't notice the overhead cut-off unless you run some benchmark test.

      Delete
  2. AnonymousAugust 17, 2017 at 1:01 PM

    Hi,

    Compiled fine, running on Ryzen rig w/o crashes.
    BUT, dreaded Diablo III stutter is back. Latest working version was 0.96f (just tested).
    With 0.97 stutter behaves a little different, it works fine for couple of seconds (approx 85FPS on my videoshitcard) and then comes the stutter down to approx 4 FPS for some seconds, then it goes back to normal and repeats.
    I tried "ondemand" and "performance" which doesn't make a difference.
    Kernel: 4.12.8 + VRQ 0.97 + 250HZ (no tickless).

    Br, Eduardo

    ReplyDelete
    Replies
    1. Alfred ChenAugust 17, 2017 at 5:51 PM

      @Eduardo
      Would you able to help debuging which commit in 097(total seven commits) introduce the stutter issue by adding them one by one upon 096f? My best guess is "f46ffc1d7185 vrq: deadline adaption."

      Delete
    2. AnonymousAugust 18, 2017 at 1:29 AM

      @Alfred,

      Will try that later today. Will start with fixup and then comes the deadline one.

      Br, Eduardo

      Delete
    3. AnonymousAugust 19, 2017 at 10:02 AM

      @Alfred,

      I did quite a lot of testing and have tested all commits, the real culprit is the 7th commit (9ee6a78860db3b670e718920328028788c18ac63) "Refine SMT code path in task_preemptible_rq()"!
      I took 4.12.8 kernel applied 096f and then added commit one by one, eg. when I refer to 6th commit, that means 1-5 are also included.
      In addition to that, I tested 4.12.4 + 096f which does not have any issues mentioned here.

      I have to say that, there was one minor issue as well, up from 1st (0671dc56e6f824075680ef99b2ede1891c66591a) to and including 6th (de5a7eb039dedd2069124088ebaac6967e46c87a) commit there is a small, noticeable and repeated drop in frames. Every 10 seconds there is a framedrop of about 10-15 frames. Its happening like this: stable FPS for 10 seconds, drop, stable for 10 secs, drop, etc.
      Of course upon adding 7th commit, all goes to almost constant stutter.

      Hope this helps to isolate the issue.

      Br, Eduardo

      Delete
    4. Alfred ChenAugust 21, 2017 at 5:19 PM

      @Edurado
      Very interesting founding, it's just refactoring in that commit. I have just sent you a debug patch by email. Thanks for testing, :)

      Delete
    5. jwh7August 24, 2017 at 8:21 AM

      Eduardo, you say that 4.12.4 + 096f had no issue; did you test 4.12.8 + 096f, or start with 4.12.8 + 096f + 0671dc5, where you started getting a 10-15 frame drop every 10sec?

      Delete
    6. Alfred ChenAugust 24, 2017 at 5:14 PM

      @jwh7
      That's a good question. I'd like to ask the same, but focus on the major one firstly.
      @Edurado is waiting for his test machine availiable to continue the testing. Let's wait for it.

      BTW, I have switched 4.13 rc release, the suspend/resume seems more reliable, mainline finally fix something.

      Delete
    7. jwh7August 25, 2017 at 10:33 AM

      I updated my 096f build with these (note my reply):
      https://groups.google.com/d/msg/bfq-iosched/H_92hgaqgIQ/2Hg44uOxBQAJ
      Ran both x64 and x86 but haven't tested resume yet...but it's lying in wait; suspended now. :)
      Anyone (Oleksandr?) know of other bfq patches for 4.12? I had a hell of a time with patches until the above link. :-|

      Delete
    8. jwh7August 25, 2017 at 10:38 AM

      I also tried building 4.13-rc last week, but gave up when I saw those patches. Not to be greedy, but do you have a working branch for vrq on 4.13, or you're just testing 4.13-rc vanilla? Thanks as always Alfred!

      Delete
    9. AnonymousAugust 25, 2017 at 11:24 AM

      Mmmh, the BFQ is really confusing me, too. The only easy (?) way I found was to take the patches Oleksandr considered worth including into his -pf kernels. My list is a little different, commit numbers taken from https://github.com/pfactum/pf-kernel/commits/pf-4.12 -- two or three commits already went into the regular 4.12 kernel by now.

      01.) 481bca0848c3
      02.) 049c9dd7fa54
      03.) a6ffda616ada
      04.) ab5ec92a3224
      05.) fd599d590a45
      06.) 512e1995c5d2
      07.) 1fce2ee66f65
      08.) cdfeba9df845
      09.) 90c365ea0712
      10.) 0c67fe05da26
      11.) b5b1c5fa9219
      12.) a6e5722e54c8
      13.) 5d313d574712

      I really hope that the list is complete. If you don't want to bother with fetching them on your own, please leave me an email address and I'd send you all patches in one archive.

      BR, Manuel Krause

      Delete
    10. AnonymousAugust 25, 2017 at 11:41 AM

      Brainflocked me... ;-) You don't need to expose your email address. I've uploaded the .tar.gz here: https://workupload.com/file/cRJ4BPT

      Have fun,
      Manuel

      Delete
    11. jwh7August 25, 2017 at 7:51 PM

      Thanks Manuel; got 'em. :-)

      Delete
    12. AnonymousAugust 29, 2017 at 12:17 PM

      Great thanks to Oleksandr for his hard work on his -pf kernels!
      Five new commits for blk-mq + BFQ I/O scheduler got available for kernel-4.12 in his github repo (see link above). Applies and compiles fine.

      BR, Manuel Krause

      Delete
  3. kernelOfTruthAugust 26, 2017 at 12:02 PM

    Approved ! :D

    The UI is still snappy and reactive while compiling Android ROMs or heavy load in general,

    snappier than previous iterations of VRQ ...

    Great work !


    Hardware: Intel(R) Xeon(R) CPU E3-1245 v3 @ 3.40GHz [performance governor ]


    Naturally we can't quite reach rt-kernel in snappiness and latencies with all the changes throughout the kernel and different subsystems but it looks quite good,

    the main issue with CFS, ck (MuQSS, VRQ) so far was always that somehow the PCIe (?) system, especially the network transfers were suffering under heavy load [also seems to be a case under Windows 10, so driver/hardware limitation (of the internal bus, scheduling-wise ?), 64-bit issue or otherwise ?] except for rt-kernel

    Consequence was that upon entering the URL the browser simply would wait for several seconds (10-20-30 seconds or even minutes) until loading the website.

    The ultimate "stress" tests for this is compiling webkit-gtk, chromium or libreoffice with the first 2 being the worst while trying to browse the web and do other stuff (watching youtube, listening to music, etc.)

    Since the packages are up-to-date right now and it's hot outside I can tell more when there is more updates available ;)

    Thanks a lot !

    ReplyDelete

Subscribe to: Post Comments (Atom)