Wednesday, July 26, 2017

VRQ 0.96e release

VRQ 0.96e is released with the following changes

1. Remove unused run_list in task_struct.
2. Fix x32 compilation error. Reported and fixed by pf.
3. Sync-up try_to_wake_up_local().
4. cpu affinity fix. Reported by pf.

This is bug fix release.

Enjoy VRQ 0.96e 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.

BR Alfred 
Posted by at
Labels: , , , , ,

12 comments:

  1. Oleksandr NatalenkoJuly 26, 2017 at 10:15 PM

    Many thanks. I'll check this ASAP.

    ReplyDelete
    Replies
    1. Oleksandr NatalenkoJuly 26, 2017 at 11:57 PM

      OK, I've built a new kernel, and cannot reproduce the issue so far as well. If nothing pops up (I'll leave a VM spinning for the workday), let's assume you did a great job :).

      Thanks again.

      Delete
    2. Alfred ChenJuly 27, 2017 at 12:23 AM

      NP. Thanks your testing effort :)

      Delete
    3. AnonymousJuly 27, 2017 at 2:32 PM

      @Oleksandr & @Alfred:
      I'd like to thank you both for your wonderful co-operation in testing and bug-fixing in the last thread!
      On my machine the latest patch also works fine.

      For people, also using the in-kernel BFQ I/O MQ scheduler from Algodev/Paolo, but not the -pf kernel, you are encouraged to apply some fixes, that can be found on post-factum's github:
      * https://github.com/pfactum/pf-kernel/commit/512e1995c5d29c524630b5f47eec5de6f74f33cb
      * https://github.com/pfactum/pf-kernel/commit/804a461415167ecc15291ef1cb219f385c3aee2f
      * https://github.com/pfactum/pf-kernel/commit/fd2229a6ea10fa78032c9d9dfc8c8261e7c84a30

      Use them upon Eduardo's mentioned fixes from last thread. No warranty for your system, but all works well on here for hours now.

      BR, Manuel Krause

      Delete
    4. AnonymousJuly 28, 2017 at 1:20 AM

      @Manuel
      thanks for the recommendations. Tested it on both machines. i7 with bfq-mg froze as before. Ran the test on Ryzen with bfq and it seems more promising, no problem so far. I will test it more thoroughly after the weekend.

      BR,
      Dzon

      Delete
    5. AnonymousJuly 28, 2017 at 12:33 PM

      @Dzon:
      Thanks for your testing. And -- the sad news -- stability is sth. different. :-( Even more weird is that your two systems atm. behave differently.
      Oleksandr also has done a summary upon this on https://pf.natalenko.name/news/ from 28th and 25th July.

      Can be that we've left out some patches for the implemented to work properly? Or the "final" bugfix for BFQ has still to come with next week's testings.
      On my system things are still fine. Please keep us informed about your progress/ regressions.

      Thank you and BR, Manuel Krause

      Delete
    6. AnonymousJuly 31, 2017 at 11:35 PM

      @Manuel
      sorry, I didn't explain it clearly. They don't behave differently. I just tested bfq-sq on one machine and bfq-mq on the other for conserving time. bfq-sq works on both machines. I applied 5 patches, but one of them was already applied (build process is pulling quite recent versions from Algodev-github). I will try to investigate today. Thanks for your help.

      BR, Dzon

      Delete
  2. AnonymousJuly 27, 2017 at 11:19 PM

    Working fine here on i7 for about one day, 4.12.3 + tickless + 300HZ. No issues as far as I can tell.
    Not using BFQ yet.
    Will test, probably, this evening on Ryzen rig.

    Does this include "enqueue/dequeue overhead" fix or "improvement of smt sensitive scheduling"?

    TY Alfred.

    Br, Eduardo.

    ReplyDelete
  3. AnonymousJuly 30, 2017 at 11:13 PM

    @Alfred,

    This version runs fine on Ryzen box as well, but on my old Phenom II couple of games my kid plays stutter, it looks like kind of heavy microstutter. Games he tried were Rocket League and Witcher 2, both are native linux executables. I taught him how to switch between kernels and he tried playing on standard Ubuntu 4.10 kernel which worked totally fine.
    VRQ is NO_HZ_FULL + 300HZ and standard Ubuntu is just HO_HZ + 250HZ, he uses nVidida 1050.
    I guess I'll compile just NO_HZ kernel w/ VRQ and then I let him try again, but my experience shows that NO_HZ_FULL does not have such microstutter effect.
    I installed previous VRQ for 4.12 on that box and they all inhibit the same stutter. So it's not just 96e, but I haven't tried previous (pre 4.12) versions on that box.
    I keep You informed as I find out more about this.

    Br, Eduardo

    ReplyDelete
    Replies
    1. Alfred ChenJuly 31, 2017 at 4:25 AM

      Try CONFIG_NO_HZ_IDLE and combination of different sched_yield_type, see which one helps.

      Delete
    2. AnonymousAugust 1, 2017 at 9:45 PM

      @Alfred,

      It seems that NO_HZ_IDLE did the trick. First I set yield_type to default without recompilation (it was forced to 0 at boot), stuttering minimized, but there still was some sort of stuttering.
      Then compiled with NO_HZ_IDLE and at least initial testing does not show stuttering anymore. An interesting and counterintuitive find for myself :)
      Anyhow, sorry for noise and thanks.

      Br, Eduardo

      Delete

Subscribe to: Post Comments (Atom)