Sunday, 18 February 2018

linux-4.15-ck1, MuQSS version 0.170 for linux-4.15

Announcing a new -ck release, 4.15-ck1  with the latest version of the Multiple Queue Skiplist Scheduler, version 0.170. These are patches designed to improve system responsiveness and interactivity with specific emphasis on the desktop, but configurable for any workload.

-ck1 patches:
Git tree:
MuQSS only:
Git tree:


The major change in this release is the addition of a much more mature version of the experimental runqueue sharing code I posted on this blog earlier. After further experimenting and with lots of feedback from users, I decided to make multicore based sharing default instead of multithread. The numbers support better throughput and it should definitely provide more consistent low latency compared to previous versions of MuQSS. For those that found that interactivity on MuQSS never quite matched that of BFS before it, you should find this version now equals it.

In addition, the runqueue sharing code in this release also allows you to share runqueues for SMP as well so you can share runqueues with all physical CPUs if latency is your primary concern, even though it will likely lead to worse throughput. I have not made it possible to share between NUMA nodes because the cost of shifting tasks across nodes is usually substantial and it may even have worse latency, and will definitely have worse throughput.

I've also made the runqueue sharing possible to be configured at boot time with the boot parameter rqshare. Setting it to one of none, smt, mc, smp is done by appending the following to your kernel command line:

Documentation has been added for the runqueue sharing code above to the MuQSS patch.

A number of minor bugs were discovered and have been fixed, which has also made booting more robust.

The -ck tree is mostly just a resync of previous patches, but with the addition of a patch to disable a -Werror CFLAG setting in the build tools which has suddenly made it impossible to build the kernel with newer GCCs on some distros.



  1. The patch for disabling the -Werror in kernel compilation works wonders. I now can patch my kernel and compile it successfully, as well as enjoy the better throughput and responsiveness. Thanks much!

  2. Compiles & boots fine. Compilations & games running great (default MC + 100HZ here).
    But, I noticed that on my Ryzen system, CPU frequency is rather high, for seemingly idle system it's around 3GHz almost all the time, while vanilla and PDS sits nicely at about 1.3-1.5GHz.
    I don't know if this is an issue per se, but it seems kinda unusual.

    BR, Eduardo

  3. Hi,

    On a Phenom ii X6, 4.14 with muqss scheduler ( Gentoo ck-sources ) is able to boot but 4.15 hangs at “acpi: pci interrupt link [lub0] enabled at irq 23” and a blinking cursor,
    rqshare=smt, none and disabling muqss work.

    Muqss locality from /var/log/debug from working rqshare=none

    0 to 1: 2
    0 to 2: 2
    0 to 3: 2
    0 to 4: 2
    0 to 5: 2
    1 to 2: 2
    1 to 3: 2
    1 to 4: 2
    1 to 5: 2
    2 to 3: 2
    2 to 4: 2
    2 to 5: 2
    3 to 4: 2
    3 to 5: 2
    4 to 5: 2

    1. And what about rqshare=mc? I'd imagine the issue being SMT sharing in particular. At least, that's what I'm getting from it anyhow.

    2. Never mind, misread what you wrote. Apologies.

    3. rqshare=mc hangs

    4. What about rqshare=smp ?

    5. rqshare=smp hangs in the same way

    6. Darn. Well rqshare=none is the same as the previous version muqss behaviour. Booting is always such a fragile process and different every release :(

    7. @Hanging Anon -- Does this also occur with 4.14? Here's the git for Con's 4.14 that includes rq sharing:

      For me, 4.14 boots fine with rqshare=mc. Can't try 4.15 yet, not going to compile the thing myself and Liquorix is not yet synced with 4.15. But it's worth a shot.

      Not that I am trying to discount the possibility of it being related to rqshare=mc. Just to rule out the possibility of it also being linked to 4.15, one of the larger kernel releases in the past few years.

    8. It seems the Phenom family in particular is having issues booting with rqshare=mc going by the comments on “Runqueue sharing experiments with Muqss” post.

    9. You mean comment. It was one person only.

    10. One had an X6 and a reply had a X4 965.

    11. Liquorix finally synced with 4.15 so, just tested it, rqshare=mc on 4.15. Not a problem here. And, not a Phenom. Still an AMD though. So, it's not an AMD issue.

  4. Thank you very much!

  5. One had an X6 and a reply had a X4 965.

  6. Wow! E8400 runs like a dream. Very thanks.

  7. Thank You for the resync.
    I had no scheduler related problems with this kernel.

  8. @ck,

    Noticed the following on my Thinkpad X220 [sandybridge] and can reproduce it on my Thinkpad T440s [haswell] and am wondering if you or anyone else has seen this happening. Following table contains booted kernel
    version in the order of their testing along with their 1 min load average approximately 5 min after booting with only i3 running (with all ck packages coming from Repo-ck by graysky @ the Archlinux forums):

    linux-ck-sandybridge-4.15.5-1 = ~1.0
    linux-4.15.4-1 = ~0
    linux-ck-sandybridge-4.14.19-1 = ~0
    linux-ck-sandybridge-4.15.7-1 = ~1.0

    Everything else was kept identical except switching between ck and stock kernels or downgrading and upgrading the ck kernel between boots.

    The constant ~1.0 average load causes the machines to run a few degrees C warmer than usual, which is how this caught my attention. Nothing obvious or out of the ordinary in CPU activity or output from:

    ps -aux

    Didn't come across any similar reports on the last few pages of Archlinux ck forum thread or here, so apologies in advance if I missed something.

    So is anyone else seeing increased load averages (with no obvious source) between ck 4.14 -> 4.15?

    Thanks in advance,


  9. negative, 4.15, Wolfdale:
    Tasks 66, 147 thr; 1 running
    Load average: 0.02 0.10 0.31
    Uptime: 03:51:01

  10. positive, 4.15, ck-atom
    load ~1,5
    maybe Xorg?

    1. I think there's something wrong with how load is counted, but in reality everything is fine and the hardware is not really under load. If you compare what's shown in "turbostat" with what's happening in "top/htop", the CPU usage in top/htop seems to be wrong.

      The following filters turbostat's output to just CPU usage:

      sudo turbostat --show CPU,Busy% --quiet

      or like this for only the average:

      sudo turbostat --show Busy% --cpu '' --quiet

      If you look at that, you'll see what I mean.

    2. Hey,
      Thanks for your explanation. I did try turbostat and frankly it shows different results, however they are still not reassuringly low. What about increased heat? Thanks

    3. Winter is almost over.
      It`s getting warmer already.

    4. I wasn't saying it's not bad that load is high. I was mentioning turbostat just to show something maybe interesting about the problem. I'm guessing it means there is no problem in Xorg and such.

      I'm guessing the problem is purely in how stuff gets counted somewhere in the kernel. This hopefully then means that for people that already use 'performance' governor, there's not really more heat.

      But for people using 'ondemand' governor, I'd assume CPU MHz is being set wrong and too high because of the wrong load numbers, so for those people there should be more heat, I guess?

      Something to try would be the 'schedutil' governor if there's a MHz problem. It might behave differently.

    5. Do you have CONFIG_NO_HZ_IDLE enabled? At least on 4.14-ck1

      - CONFIG_NO_HZ_IDLE + conservative governor = sometimes the selected frequency is higher than expected
      - CONFIG_HZ_PERIODIC + conservative governor = good frequency selection

      With CONFIG_HZ_PERIODIC the system still runs a bit warm probably due to the periodic interrupts preventing it from entering the C* states.

  11. Thanks Con.
    I did some throughput & interbench tests with MuQSS 150 on my 4770k.

    On this kind of cpu, what's the difference between rqshare=mc and rqshare=smp ?


    1. I assume you meant muqss 170 where you wrote 150 everywhere. MC and SMP sharing on that kind of CPU are identical so any differences you are seeing are simply showing the wide variance in your results.

    2. You are right. It was a mistake.
      Thanks for clarifying the MC and SMP sharing on my CPU.
      And thanks for your continuous efforts in maintaining and improving MuQSS.


    3. Well so which process scheduler has won?
      I have a PSD scheduler of processes constantly lagging in the graphical interface.
      MuQSS is the best in this case.

    4. Well, by those numbers alone, PDS actually seems the best, the most well rounded scheduler. But, like you said, you're experiencing a laggy UI while using it.

      Which does actually account for a great deal as well. Performance only goes so far; the user experience is at least as important, if not more so.

      And, my experience is the exact same as yours, MuQSS simply provides the most smooth desktop experience.

    5. MuQSS with RQsharing (mc) wins.

  12. OK. CPU load, etc. is way off.
    But I don`t care as long as the performance is there, and it is.

  13. Although I compiled BFQ into the kernel I can`t use or choose it.

    cat /sys/block/sda/queue/scheduler
    [noop] deadline cfq

    1. elevator=bfq in kernel parameters shows this in dmesg:

      [ 0.210536] I/O scheduler bfq not found

    2. Found something:

    3. OK.
      Solved it by adding scsi_mod.use_blk_mq=1 to kernel parameters.

      cat /sys/block/sda/queue/scheduler
      [mq-deadline] kyber bfq none

    4. Please don't use bfq with kernel 4.15, its broken. Check!forum/bfq-iosched for details. The fix is already be done, but it seems, that it will not go into 4.15 anymore. For me the error shows quick up in mounting a NTFS USB thumb drive, a simple "blkid" hangs in D state (together with udev process). Workaround, change your udev rule, not using BFQ for all (new) drives or better use zen-kernel with the integrated BFQ-MQ (which is BFQ next ;) ), where the patch is already integrated. Works for me super.

      cat /sys/block/sd?/queue/scheduler
      mq-deadline kyber bfq [bfq-mq] none

      Regards sysitos

    5. Thank you very much, sir.

    6. One question, can I patch MUQSS into the zen kernel?

    7. Or use pf-kernel, where I have backported fixes needed for BFQ to work properly.

    8. Or is there a way to get the bfq-mq patch(es)?

    9. Zen kernel is with muqss, bfq-mq, exfat and some other tweaks already included. A simple "git clone" of and than after a new kernel release a "git pull" to stay current.
      The pf-kernel from Oleksandr is similar, but without the exfat driver and I dont like the versioning, the kernel stays at 4.xx.0-pfxx, so I don't see immediately the actual patch number of the main linux kernel. All imho. But anyway, thanks Oleksandr for your work.

      Regards sysitos

    10. OK.

    11. @sysitos:
      IMO, complaining about Oleksandr's kernel naming scheme is not appropriate and no reason not to use or try it.
      In my experience he always did and does a great job to add valuable patches to his combo, some even picked from future releases, making his github repo a good source of information about what's going on in the cpu-/ disk-scheduler- world (etc.).
      I also don't like his naming scheme, for me it confuses GRUB2 boot menu, but he ships with the "apply to bare vanilla .0.0 kernel" and it's a clear announcement.
      We are all free to edit the top Makefile or new patches, w.r.t the release notes, to indicate the current kernel version.

      Regarding the BFQ-MQ, I also hope that both, kernel configuration and the ability to distinguish MQ from the older SQ one at runtime, would be easier.

      Best regards,
      Manuel Krause

    12. @Manuel, sorry, but what would you like to say to me? Maybe my german - english translator is as bad as yours, but nowhere I wrote, that anybody or I shouldn't use the pf-kernel. So don't blame me. I use both kernels, they are similiar with differences, so I wrote. There was a time, Oleksandr had even the PDS scheduler within his patchset and zen-kernel was some versions behind the mainline kernel.
      And I know, which great work is Oleksandr doing, he is mostly the first who test and check the new CPU schedulers (from Con or Alfred) or is bughunting on BFQ or other things.
      But anyway, here again, thanks Oleksandr for all your work. And to stay not offtopic at all, thanks Con for your MuQSS too. It does a good job here with SMT on an i7.

      Btw: zen kernel has BFQ-SQ, BFQ (mainline) and BFQ-MQ (BFQ next). So if you dont use the mq, you can still use the BFQ (some time ago there were huge problems with i386 and mq, discovered/described fine by Oleksandr too.)

      Regards sysitos.

    13. I recently had problems with algodeb (git) version of BFQ-MQ on I386.
      But Oleksander's patch for mainline BFQ seems fine.

    14. Typo. I meant "Algodev-github/bfq-mq".

  14. About BFQ and PF, you don't need whole patch (and you can't apply it anyway for updated kernel from your distro). Just extract BFQ part and apply it. Oleksander has well organized patch so you won't miss anything.

  15. Simple patch to make BFQ default MQ Device for SCSI
    In /block/elevator.c
    change default elevator for SQ devices from mq-deadline to BFQ
    if (q->nr_hw_queues == 1)
    - e = elevator_get(q, "mq-deadline", false);
    + e = elevator_get(q, "bfq", false);

  16. His Oleksandr