Monday, March 25, 2019

BMQ 0.91 release

BMQ 0.91 is released with the following changes

1. Fix BMQ compile fails for x86-UP, again. Thanks pf's code review.
2. treat NORMAL task as dl for lower ttwu latency.
3. Remove uprq. Unified code base for UP and SMP.
4. Rework task switch time thresholds.
5. Rework sg_balance_trigger(). Add one more trigger scenario.

This is improvement release of BMQ. #4 will provide more distributed boost range, users can notice this by watching the cpu monitoring tools.

Enjoy BMQ 0.91 for v5.0 kernel, :)

Full kernel tree repository can be found at
And all-in-one patch can be found at gitlab.

Please report bugs at


  1. @Alfred:
    Compiled and booted fine with kernel 5.0.4, now works well for me for ~6h.
    It's quite difficult to distinguish differences to BMQ 0.90, but I don't experience any regression. :-)
    You've done great work with the new BMQ scheduler!

    Best regards,

  2. Hi @Alfred, it's i anon with problem vulkan, with patch and bmq091, result after a time system unfreezed, (aka system not fully dead, this is the best result, with what was), *waiting yield_type 2* good luck @Alfred!

    1. and after unfreeze game dead(black screen), needed restart.

    2. Thanks for the feedback. Will work for another yield solution.

    3. Did some tests with yield_type, and found that when doing a benchmark + a make -j12 in the background, the default yield_type of 1 had a horrible result.
      Setting yield_type to 0, + the nVidia driver with __GL_YIELD="USLEEP" seemed to get the best benchmark score.

      Previously this USED to be with yield_type=2, but that is not available as you say.

      The benchmark was run with -5 nice value, so in theory a yield_type of 1 should have given a better result for the -5 task (the benchmark) right? (This is with BMQ 0.91 + the above patch).

      Up to experimentation i guess.

  3. Built and running on x86-UP netbook; thanks Alfred!

  4. Thanks.
    Nice performance but can you please make the timeslice tunable?
    For slower CPUs or server use it would be better to increase/adjust it.

    1. CONFIG_SCHED_TIMESLICE is tunable, but it's not recommended b/c some thresholds based on timeslice is still not finalized.

    2. OK.
      Thanks for answering.
      I meant tuning at runtime.
      Compiling a new kernel each time seems rather time intensive.

  5. Alfred, can you suggest the optimal settings for:
    - Hz: periodic, no_hz, no_hz_full
    - Preemption: server, desktop, preempt
    - Tick frequency: 100, 250, 300, 1000
    Thank you!

    1. This is probably individual, cos there are just as many recommendations from various kernelhackers as there are options.
      Love to hear Alfred chime in on this ofc, as he would know a bit more what to expect from those tunables when it comes to BMQ.

      However, from my own testing with PDS and some BMQ, i think i would conclude with the following: (This is for a DESKTOP rig used for gaming and whatnot)
      Hz: no_hz (CONFIG_NO_HZ=y, CONFIG_NO_HZ_IDLE=y)
      Preempt: preempt (CONFIG_PREEMPT=y)
      Tick: 1000hz. (CONFIG_HZ_1000=y, CONFIG_HZ=1000)

      You might get slightly better max perf from choosing hz=100 at the cost of a bit less "snappy" feel tho, so its more up to experimenting.

      BMQ performs a wee bit different than PDS, so as i said, i would love to see a comment from Alfred ofc :)

    2. Hi,
      I've also made good experiences with the above settings for PDS. Some day I changed to CONFIG_HZ_PERIODIC=y for some reliability testing. The latter would be more energy consuming, as I understood it.
      1000Hz are good for interactivity and PREEMPT should be mandatory for this goal, too.
      Of course, you should test these parameters according to your needs.
      For BMQ091 these settings work as well as with last PDS from @Alfred, IMHO.

      But I'm curious for @Alfred's more experienced mind's answer on this, too.

      Best regards,

    3. For the default kernel (without PDS or BMQ) on the Raspberry Pi 3:
      Hz: FULL
      Preempt: Desktop
      Tick: 300Hz

      I then reserve the first core for all housekeeping and interrupt activity, which the emulators and supporting processes run without interrupt on the remaining 3 cores.

      This provides the best balance between performance and latency. I'm also using these settings for BMQ now, but maybe Alfred will recommend some slight changes.

    4. As discussed before, all these setting is related to system performance under certain usage. But they are not related to cpu scheduler itself. So I would like to not recommend these settings, and let the users to tune for their usage.
      And it's good to see users have shared their settings here.

  6. Hi, works OK on Ryzen 1700 and 2400G, both at home and ok on i7@work, BUT issue with sound crackling while saving libreoffice docs is still here since last releases of PDS. I use old school media player called Apollo37z (yes, that's old as old it can be :D) through wine.
    Annoying :(
    BR, Eduardo

    1. Hi, @Eduardo!
      Is there a reason to use this way of media playback? I use smplayer (KDE) frontend for /usr/bin/mpv and don't experience any stuttering or crackling when having high loads (e.g. normal prio kernel compiling). Also media playback from german broadcasting websites through their various players within Firefox doesn't suffer.
      Maybe time to change your media playback routine? ;-)
      BR, Manuel

    2. Agreed, you should give DeaDBeeF a try.

  7. Hi, @Manuel!
    Let's look at this from different POV. This has not been a problem for me for like 9.6 years out of 10. Now, somehow, it starts to misbehave, but it's still an extremely simple application in wine and runs rather well on different schedulers.
    The same argument of Yours could be applied to Diablo3, which I played back in the day and it stuttered, why don't change that to say OpenD2, which is native, right... Well, not exactly :)
    I hope You see my point ;)
    I'll try to use vanilla or muqss for a while to see whether similar symptoms appear there too. I'll post my findings.
    BR, Eduardo

    1. @Eduardo
      Pls report bug to
      You reported similar issue for PDS if I remember correctly, and it has been fixed in PDS. It's caused by burst creating tasks which take too many cpu time and make other tasks starving. I'll see what can be done in BMQ.

    2. @Alfred,
      I'll do that, but I'll gather more info before.
      BR, Eduardo

    3. @Eduardo
      You can also try this workaround. Use "nice" cmd to adjust your music player priority. I believe nice --10 will be a good start point.