Tuesday 15 August 2017

linux-4.12-ck2, MuQSS version 0.160 for linux-4.12

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


-ck2 patches:

Git tree:



Git tree:

Sorry about the delay. I skipped announcing 4.12-ck1 as there was a lingering bug report from pf (thanks for extensive report!) and a config problem in it that rendered it unbootable without extra confg options.

MuQSS 0.160 updates

- Fixed race leading to crash on use of sched_setaffinity.

4.12-ck2 updates

- BFQ is now in mainline so it is no longer part of the patchset.
- BFQ now enabled by default along with scsi multiqueue to enable booting with it by default.
- Enable setting new kyber I/O scheduler as default as well (I recommend people use BFQ though.)
- Removed the mandatory swap_full() flag in the swap sucks patch after reports saying it was unhelpful.



  1. If CONFIG_SMP=n is set, the following warning appears:

    In file included from kernel/sched/sched.h:2:0,
    from kernel/sched/idle.c:19:
    kernel/sched/MuQSS.h:270:0: warning: "task_rq" redefined
    #define task_rq(p) cpu_rq(task_cpu(p))

    kernel/sched/MuQSS.h:262:0: note: this is the location of the previous definition
    #define task_rq(p) (uprq)

    Should "#define task_rq(p) cpu_rq(task_cpu(p))" be moved under #else section (where the code for CONFIG_SMP=y variant is defined)?

  2. Like this: https://gist.github.com/423338a9f73ca01a3e6071afdd7db758


    1. @ck - Is ck2 setup correctly to use bfq as the default scheduler?

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


      zgrep -i bfq /proc/config.gz

      % zgrep -i deadline /proc/config.gz
      # CONFIG_DEFAULT_DEADLINE is not set

    2. It's set but it's very easy to override the default setting when inheriting old configs.

    3. Yes that looks about right PF.

    4. Please see https://bbs.archlinux.org/viewtopic.php?pid=1730573#p1730573 Edit 8 onwards for why the config option has no effect.

    5. There was a patch somewhere in the mailing list to implement DEFAULT_MQ_IOSCHED which I haven't seen pushed yet when I was looking to maintain the AUR package for linux-bfq-mq.

      You can use:

      sudo tee/sys/block/sda/queue/scheduler <<< bfq
      echo bfq > /sys/block/sda/queue/scheduler

      in your rc.local or related startup script.

    6. Don't do this, you have udev rules for it.

  3. Well look like the merged bfq is a block-device that only can be enabled using udev rules and not honout elevator and aparently in some forums user claim that it modprobe-able...

    so the bfq mailined eternally look realy like a diferent thing so my question is: Does the mailined bfq is the same as you has developed?

    1. Paolo Valente developed bfq (I apologize, I have to give credit to his amazing work).

      As of 4.12, bfq in mainline is strictly bfq-mq and not the single-queue iosched that ck has added out-of-tree. Patches for the single-queue elevator bfq-sq has added in the main bfq-mq repository and is probably planned for mainline 4.13.

    2. BFQ-SQ will never enter upstream kernel. It is deprecated.

    3. Ah right, blk is getting deprecated.

  4. I just want to say thank you for your amazing work. I've been using your kernel for so many years now and can't imagine using anything else.

    Everybody who compiles code on a regular basis will notice a dramatic difference between this kernel and mainline in terms of responsiveness when using something like make -j 8.

  5. After upgrade to 4.12 from 4.11 my computer does not wake up from sleep. I am running Intel CPU and AMD GPU.

    1. Apparently, some users on Archlinux reddit found out about this problem due to blk-mq when using BFQ.


    2. After applying mentioned patches I am still having the same problem.

    3. Looks like it's not related to MuQSS.

  6. This comment has been removed by the author.

  7. Hi, thanks for your work, much appreciated :-)
    However, I am getting hard CPU lock-ups after applying both -ck1 and -ck2 patches to 4.12. It's an AMD X6 processor from a while back.

    I can reproduce this easily by compiling the kernel with 'make -j 6 rpm-pkg' and then playing back some video with VLC.

    dmesg output: "[ 1265.189377] NMI watchdog: Watchdog detected hard LOCKUP on cpu 2" If needed, I saved more dmesg info. I am not able to reproduce without -ck2 patch applied. (It happens both with BFQ and CFQ io schedulers.)

  8. The load average seems to be broken after waking the laptop after suspend to ram:

    19:42:11 up 3:12, 1 user, load average: 4686378937.86, 1114499707436.02, 2827926430752.02

    Any more information I can provide?

    Linux flxtp 4.12.9-2-ck-nehalem #1 SMP PREEMPT Fri Aug 25 15:31:46 EDT 2017 x86_64 GNU/Linux

  9. Thinkpad X230
    mq-deadline kyber [bfq] none

    I am experiencing the same broken suspend problem as mentioned earlier. The system wakes up and instantly freezes on the login screen. Keyboard, mouse etc unresponsive. Can't switch into tty either. Also nothing interesting shows up in journalctl. Only solution is hard reset.

    1. You are free to follow relevant discussion in linux-block mailing list. The issue is not fixed yet in the upstream, but there are some patches circulating around, and some were merged into -pf making suspend-resume with blk-mq reliable.

    2. Thanks for your reply Oleksandr. Can you please let me know if there is any Arch repo that provides cpu optimized linux-pf or linux-zen packages like repo-ck?

    3. I build it myself for Silvermont, Skylake and generic x86_64, links are there on pf-kernel site. If you need it for another architecture — you are on your own.

  10. I somehow managed to get my personal PKGBUILD for linux-pf into some shape so I can share it on the internet. You might wanna try using the AUR package https://github.com/pinkfluid/linux-mpf . It will autodetect your local CPU and build for that platform.

    1. This was supposed to be the answer to the thread above about the Arch repo for linux-pf.