Thursday, December 19, 2019

BMQ v5.4-r1 release

BMQ v5.4-r1 is released with the following changes

1. Adjust task boost_prio at deactivate&wake_up.

This change makes task which gives up CPU longer than a time slice a priority boost when it wakes up. And now, children tasks fork from high boost priority tasks will have relative higher boost priority than the original lowest boost priority.

Enjoy BMQ for your linux kernel, :)

Full kernel tree repository can be found at https://gitlab.com/alfredchen/linux-bmq
And all-in-one patch can be found at gitlab.

Bug report at https://gitlab.com/alfredchen/bmq/issues

8 comments:

  1. Up and running without issues.
    I will get an 3970x to play with and will report back how BMQ runs on that monster.

    ReplyDelete
  2. It has been running fine since release on i7@work and Ryzen@home.
    Thanks and Happy New Year, Alfred!
    BR, Eduardo

    ReplyDelete
  3. Some interesting stuff on Con Kolivas blog:
    https://ck-hack.blogspot.com/2020/01/happy-new-decade.html

    ReplyDelete
    Replies
    1. I was linked from https://www.phoronix.com/scan.php?page=news_item&px=Linux-2020-Scheduler-Bugs-Stadia
      Yes. I'm a phoronix reader too. :)
      The EDIT part of BMQ benchmark in https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is/ looks great.
      Thanks for whom comment BMQ to the author, I know you are here reading.

      Quick answer for the magic 4.0ms of spinlock_amd in idle load benchmark, I believe it is related to CONFIG_SCHED_TIMESLICE in kernel config, the default value is 4 in ms, and not recommended to change it at the first of BMQ release. Recently, I have practiced it in 2ms. The introduced overhead at heavy workload is acceptable. You can give it(2ms) a try and your feedback will be welcome.

      Another comment is, the author should try different yield type in BMQ as there is evil yield() calls in the source code.

      Delete
    2. quote: "among the Linux schedulers I tested, this looks to be the best one"

      Delete
  4. Happy new year all the BMQ users. I just get back and have no time to write some about next year/decade yet. May find some time to do it before CNY.
    Thank you all for the support of BMQ in the past 2019 and looking forward to 2020.

    ReplyDelete
  5. Hi, I was measuring mutexes and spinlocks and after finding some oddities, it turned out that I was actually measuring schedulers. Because different schedulers have very different behaviors for different types of mutexes and spinlocks. In any case I wrote this up as a blog post and in my comments somebody suggested to check out BMQ. It performed very well in my benchmarks (best among the Linux schedulers I tested) so I figured you'd like to hear about it. The blog post is here:

    https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is/

    Thanks for doing great work on this Linux scheduler. It is something that's needed.

    ReplyDelete
    Replies
    1. Thanks Malte to write up your wonderful blog post. It's good see more activity to observer scheduler in different ways.

      I have not yet read deeply through your post and all the comments. But pls check my quick comments about magic 4ms and about the yield type above.

      Delete