Monday, January 9, 2017

VRQ 0.91 release

VRQ 0.91 is released with the following changes

1. rework yield_to(), make it to be suit in VRQ scheduler.
2. Remove rq_deadline which is only used locally.
3. remove unused sched_interactive, there is policy based interactivity setting in VRQ, so remove this BFS scheduler system parameter.
4. Do irq_enter on scheduler_ipi called when idle to update xtime. Pick up from MuQSS.
5. Remove dup'd vtime_task_switch. Pick up from MuQSS.
6. remove unused double_rq_lock/double_rq_unlock
7. rework take_other_rq_task(). This rework provided more interactivity for RT/ISO/NORMAL tasks.
#7 is considered as a fix for D3 wine playing issue under ondemand cpufreq governor. Is it works, there would be other commits for further tuning.

Enjoy the first release of VRQ in 2017, :)

code are available at
and also

All-in-one patch is available too.

BR Alfred 


  1. Also a nice release. On my system it seems to solve some already rare audio (/video) stuttering.
    Interactivity is awesome also with kernel compiling (normal mode: -j2 for my dual core) plus video playback.
    My last mentioned issue in the last thread isn't solved by this release, though.

    BR, Manuel Krause

    1. @Manuel
      This release mainly fix D3 palying issue reported by Edurado. I'd try some new idea for task policy fairness, hopefully can be done in next release.

    2. @Alfred:
      I'm atm. suffering of a severe hibernation/resume crash with loss of much KDE session data.
      Only changed things were 4.9.1->4.9.2 and VRQ 0.90->0.91. :-(

      BR, Manuel Krause

    3. Luckily, there aren't so many commits in question. The yield_to one is my first one to revert.
      BR, Manuel Krause

    4. @Manuel
      Just try to isolate the issue by testing 4.9.1+VRQ0.91 and 4.9.2+VRQ0.90, if it is VRQ related, you can find out which commit contribute to your issue by adding them one by one(or bisect to find out).

      I am on 4.9.1 and suspend/resume works normally.

    5. @Alfred:
      It can also go well with 4.9.2 + VRQ 0.91 (it just happened) but I don't want to experiment too much with other risks. I'd recompile fresh sources.
      BR, Manuel Krause

    6. @Alfred:
      It's most likely that I've screwed up some things with my unofficial TOI port.
      Please don't hesitate to go on with your development as you planned.

      BR, Manuel Krause

    7. @Alfred:
      Yes... Sorry... It's now a fact like I've written above. The two addon TOI commits I've wrongly tried to implement just made the whole system unstable.
      Luckily my safe base TOI MOD7 patch from before is safe with VRQ 0.91, BFQv8r7 and WBT7 on kernel 4.9.2, as my actual usage testings prove.

      Have you had progress with your recent "task policy fairness" idea(s)? Maybe it's about to solve other fairness related symptoms as well. Me really looking forward to your next patch/commit to test ^^ :-)

      BR, Manuel Krause

    8. @Manuel
      Good to hear that TOI works for you again.
      I am not yet really on "task policy fairness". I worked on a cpufreq tuning for #7, but the result doesn't come out as expected. Now I am working on introducing the mainline cpu accounting code to reduce vrq scheduler code size.
      For "task policy fairness", it is similar to rq balance in mainline, so I am investigating how mainline do this job, and how to it can be best suit in VRQ. It may finally come out of 2+ solution options for testing, so it would be a feature over releases.

    9. @Alfred:
      Thank you for these news. I will (at least try to) be more patient. ;-)
      Don't hesitate to push out early patches.

      BR, Manuel Krause

    10. @Manuel
      I am definitely not good at any accounting works. Just managed to make the cpu accounting code works this weekend. This doesn't bring new feature, but it reduce the main VRQ scheduler code size under 7k LOC, which will help with further sync-up work with the mainline scheduler from release to release.
      "task policy fairness" job will be after cpu accounting is released, for sure I will release patches before next holiday, :)

  2. Hi,

    I haven't had time to check this version on my Phenom, but it's working quite fine here on Skylake laptop.
    No issues of using it for 2 days, suspend works with 4.9.2, using it here with 100Hz... I start to notice Manuel's firefox tab switching / opening delays with VRQ and MUX, I don't remember having those before. I don't know, maybe it's just "feeling" and I'm paying attention to it after I heard about it.
    I think there is nothing to worry about for You, Alfred, as kernel seems to work fine, freq scaling works pretty good, have not see any strange stuff.
    When I set this up in Phenom, I'll report back.

    Br, Eduardo

    1. @Eduardo:
      Regarding the firefox interactivity weirdness I can't give you a 100% exact hint on how I solved it. But I've definitely got rid of it ~at the time when Con was experimenting with his 128Hz timer microoptimisation aproach in MuQSS, that was also the time when this issue went "mad".
      I've then tried to experiment with various unusual HZ values on my own while watching interactivity, from which several power-of-2 values led to timer error messages or failing virtualbox modules (128, 256 and 1024) and stopped with 512 what appears to be good for my system -- with VRQ too.
      In a second step I've spent some hours with firefox and adblockplus, analysing my usually visited websites regarding scripts that periodically call back their "home" or tracking services and evident cpu hogging scripts. That effectively tamed firefox' cpu usage.
      And both steps together seem to do the trick. In former days (BFS) I had also noticed that FF's cpu usage increased over running time together (maybe proportionally) with this tab switching lag. This is also gone. After thinking this over again now, most likely the adblockplus work had the main effect to solve it. At least I can say that ~170 open tabs don't harm FF on my system any more. :-)

      BR, Manuel Krause

    2. @Manuel and all,
      I remember you have asked what HZ is recommended for VRQ, I guess I forgot to answer that question.
      HZ is one factor that impact system interactivity and performance, but scheduler is not the bottleneck of setting the HZ, in almost all of the time(can't said 100% here, :)). So, feel free to any HZ, and just don't get your system killed b/c of it.

    3. @Alfred,

      I have tried v091 on Phenom and I'm glad to say that D3 wine issue is solved.
      The sideeffect however is interesting. The story of performance in gaming in linux is that with ondemand governor it's rather slow compared to performance. This is true to all titles I have played, not many, as I'm not really a gamer, though. Now with this patch / v091, D3 framerate is the same using ondemand as performance governor, but before the patch it usually was half of that.
      This, so far, applies only to D3, coz I tested this in League Of Legends, which I play in wine as well, and performance decreases as I'm using ondemand compared to performance governor.
      It's interesting why D3 is behaving differently to LOL.
      I hope this can help.

      Br, Eduardo

    4. @Eduardo
      Thanks for the D3 testing. Games like all other userland applications have their own implementation. So there is no surprice they have different behavious.