Monday 3 October 2016

BFS version 0.512, linux-4.8-ck1, MuQSS for linux-4.8

This is to announce an updated version of BFS for the new stable linux kernel 4.8.

BFS by itself:

-ck patches with BFS:

EDIT: Here's a bugfix post release for the above kernels that I highly recommend you include:

Following on from the aggressive development towards a new scheduler, this BFS incorporates a number of fixes and performance improvements discovered while working on the Multiple Queue Skiplist Scheduler, MuQSS (pronounced mux) and should be the best performing BFS yet.

Note that this may be the last BFS based -ck release as MuQSS is designed to replace it, being the logical evolution of the same scheduler into a more scalable discrete runqueue design.

For those willing to try it in its current version, an incremental patch can be applied to BFS 512:


or there is a full patch against 4.8:


Again, MuQSS is still immature code and while I have been running it stably for a few days now, and have spent a lot of time debugging locking issues and stability, it is not intended for production use just yet. Having said that, all testing is most welcome, especially benchmarks and stacktraces if you get any crashes.

I've been asked numerous times why I decided to change the name. There are two major reasons. The first is that it signifies just what a dramatic overhaul to the codebase it is, where it is virtually a new scheduler, even though it uses the same scheduling decision policy as BFS. The second is that I've had many people approach me saying they would like to use BFS for their own production environment but alas the offensive name is a showstopper for them. Additionally I had to choose a name that wasn't being used by anything else which both BFS and brainfuck had been used before.



  1. That was quick ! Thanks again Con.
    I ran the usual quick tests. I reduced the number of run to 2.
    This time SMT_NICE and CGROUP_SCHED are enabled.

    I also had a problem while running MuQSS104. What I understand from the system log (it's giberrish for me) is that some kind of stall happened in one of the xfs processes and ultimately led to a crash of systemd-journald. The system didn't crash however and I was able to reboot normally. Here is the log:
    I don't know what trigger it, and if it is related to MuQSS in the first place. I'll try to reproduce it.


    1. I hope that you've had the two (atm.) pending patches applied:

      Currently the old 4.7 MuQSS with those patches works well on here.

      BR, Manuel Krause

    2. No they weren't applied. I'll try these. Thanks for the info Manuel.

      By the way, I also had two error message on two different boot with bfs512, still xfs related. But nothing with cfs so far..


    3. They're real bugs shared by both schedulers and not fixed yet by any of the pending patches.

  2. Con, given your explanation here right above, regarding your finding of a new "branding" for your scheduler evolution, it's quite some fun, what's most important for Phoronix readers to comment on... ;-) At least, until now it's not annoying.

    BR, Manuel Krause