Monday, October 21, 2019

BMQ v5.3-r2 release

BMQ v5.3-r2 is released with the following changes

1. Several optimization. Remove sched_cpu_llc_start_mask, Optimize migrate_pending_tasks() and Refine bmq_find_first_bit/bmq_find_next_bit macros. 
2. Rename some variables for readable.

Version number pattern has changed per the suggestion from users. Now there should be no confusion.

Enjoy BMQ for your linux kernel, :)

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

Bug report at


  1. Compiled and installed on i7@work, seems to work fine for whole day.
    Haven't tried to use it on Ryzen yet.
    BR, Eduardo

  2. An interesting benchmark at

    1. I'd like to comment on BMQ&PDS(should be my PDS-mq, though it was terminated at 5.x, don't know how it survive to 5.x, ;)) in this benchmark.
      One thing that doesn't be shown in the data and charts results is the cpu usage during the test. From the video, the cpu usage of BMQ&PDS testing is keeping low.
      PDS get first FPS in the(first 2) tests, but in overall, I think BMQ is better as it has better time per frame results and better FPS than PDS in the 3rd test.
      Although there is only ~3% improvement in FPS(comparing to CFS), but it(switch to a different scheduler)'s still the most easy way to get performance boost based on the given hardware.
      IMO, BMQ is much simple than PDS-mq in design and code implementation, and that's why I switch to BMQ from PDS-mq. The tests(I have done) and the benchmark from users also show BMQ is better or at least comparable to PDS-mq. It's time to move on with BMQ. ;)

    2. Results are in line what I have tested, BMQ actually achieves good results. GJ Alfred :)
      One thing that these results lack is kernel config. At least that would be interesting for me, which HZ value and tickless config (full vs tickless) :) It would be beneficial to know cpu freq governor used, although, we can pretty much assume intel pstate is used.

      Recently, just out of curiosity I have tested my compilation (this time compiled from pf kernel tree) vs pf kernel from suse repo, it seems that full tickless (arch and pf defaults) are somewhat slower in gaming tests, at least in unigine valley the results are consistently 3-4% better with idle tickless (5180 vs 5400 points) on my Ryzen and rx570 nitro. To exclude various factors, I'll compile full tickless some time to try to compare as much apples to apples as possible.

      The good difference was achieved by tweaking ondemand governor as well, that helped to achieve the same results as muqss on my hw with the benefit of low cpu frequencies when computer is idle (somehow muqss keeps freq quite high even when idle, which by itself is not exactly a problem, but lower freqs keeps my mind calm :D).


  3. Or for just the data and charts' results:

  4. Hi Alfred, can I check info of bmq using 'dmesg | grep -i bmq' or something like that? I'd like to see some strings saying that I have bmq running and nothing goes wrong.

    1. dmesg | grep -i bmq should works.

    2. So, in fact something went wrong... neither dmesg or journalctl show up something related with bmq. I'll investigate.

    3. No, it's just I decreased log_buf size and forgot to increase it again.