Monday, 16 October 2017

linux-4.13-ck1, MuQSS version 0.161 for linux-4.13

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

Git tree:


MuQSS only:
Download:

Git tree:


This version is no more than a resync from 4.12-ck2

Enjoy!
お楽しみ下さい
-ck

at

19 comments:

  1. Andreas Jacob17 October 2017 at 03:02

    It would be interesting to see if the broken suspend problem exists with this release. Personally, I love to use this kernel but the hangup after wakeup is too much to live with unfortunately.

    ReplyDelete
  2. jwh717 October 2017 at 03:40

    There have been fixes for that on linux-block for a while now. My suspend/resume has been working fine on 4.13 for weeks. I think these are key, but post-factum (Oleksandr) would know for sure, as I've pulled in a lot of other things:
    https://www.spinics.net/lists/linux-block/msg18208.html
    [OR https://www.spinics.net/lists/linux-block/msg18625.html]
    And you'd prob want this too:
    https://www.spinics.net/lists/linux-block/msg18846.html

    If you're using bfq as well though, there's a bunch of patches for that too.

    Anyway, thanks Con! Getting bored w/ the new car yet? :-P

    ReplyDelete
  3. Anonymous17 October 2017 at 07:01

    I have a kernel panic when booting a kernel build with 4.13.7-ck. This is on Archlinux with i7-6700. Kernel logs: https://ptpb.pw/kmqk

    ReplyDelete
    Replies
    1. Anonymous17 October 2017 at 08:21

      This is fixed with patch http://ck-hack.blogspot.co.uk/2017/10/linux-413-ck1-muqss-version-0161-for.html

      Delete
    2. ck17 October 2017 at 08:34

      That's not a patch, that's a link back to this page.

      Delete
  4. Anonymous17 October 2017 at 07:07

    It seems as though bfq is to blame. For me, booting elevator=cfq in the boot loader works as expected. Can others confirm?

    ReplyDelete
  5. Anonymous17 October 2017 at 07:33

    Anyone running the nvidia driver 387.12 ?
    I'm getting errors with muqss vanille is working here the error message:
    nvidia-modeset: ERROR: GPU:0: Failed to query display engine channel state:

    ReplyDelete
    Replies
    1. Con Kolivas17 October 2017 at 08:08

      There's a much newer nvidia driver. Are you limited in version due to older hardware or something? It sucks once you're in the unsupported hardware group.

      Delete
    2. mbar23 October 2017 at 22:27

      No problem here:

      emerge -pv nvidia-drivers

      These are the packages that would be merged, in order:

      Calculating dependencies... done!
      [ebuild R ] x11-drivers/nvidia-drivers-387.12:0/387::gentoo USE="X acpi driver gtk3 kms multilib tools uvm wayland -compat -pax_kernel -static-libs" ABI_X86="32 (64) (-x32)" 81087 KiB

      Total: 1 package (1 reinstall), Size of downloads: 81087 KiB

      asus-ux303 ~ # uname -a
      Linux asus-ux303 4.13.9-ck #1 SMP PREEMPT Sun Oct 22 07:36:53 CEST 2017 x86_64 Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz GenuineIntel GNU/Linux

      Delete
  6. Anonymous17 October 2017 at 08:48

    387.12 is the newest beta driver.
    I now reverted back to 384.90 which works fine.
    My card is a 1050 Ti so pretty recent.

    ReplyDelete
  7. graysky18 October 2017 at 07:07

    Hi CK. The boot freezing from my email seems to be a direct effect for BFQ. If I reverse apply 0015-Enable-and-make-BFQ-default-IO-scheduler-overriding-.patch after applying patch-4.13-ck1, everything works as expected.

    My understanding is that this will remove BFQ from the patchset though. A work around which is applied to the Arch Linux linux-zen package (that includes MuQSS) is:

    https://github.com/zen-kernel/zen-kernel/commit/3f98cead6c61156002dacb770bd9ffe20bce2752#diff-770586e82a162dbd2b70f2d5d926bac4

    That enables bfq by default in block/elevator.c that switches e = elevator_get("mq-deadline", false); to e = elevator_get("bfq", false); if #if defined(CONFIG_ZEN_INTERACTIVE) && defined(CONFIG_IOSCHED_BFQ)
    That would enable bfq by default with a one line change if you enabled CONFIG_SCSI_MQ_DEFAULT in the .config

    sq-bfq the bfq for when multiqueue is off also the bfq from before it was merged into mainline is

    https://github.com/zen-kernel/zen-kernel/commits/4.13/master/block/bfq-sq-iosched.c

    Rather than me hacking this together, I'd like for you to review and consider a ck2.

    ReplyDelete
    Replies
    1. Con Kolivas18 October 2017 at 07:16

      Thanks Graysky. It will not remove BFQ from the patchset since BFQ is part of mainline. That's why this is a most unusual bug since it is just a change in the default configuration which is doable even without this patch - it should not hang otherwise it's a mainline bug. I'll think about a -ck2.

      Delete
    2. Anonymous18 October 2017 at 09:03

      Yes it is an upstream bug as referenced https://github.com/ckolivas/linux/pull/5
      The difference between 4.12-ck2 and 4.13-ck1 is the removal of Select SCSI_MQ_DEFAULT automatically when required by default io schedulers patch. Which prevented the mismatch. Even under 4.12-ck2 selecting bfq by default fails because bfq in mainline is a multiqueue based scheduler and https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?&id=b86dd815ff74ab9eda474d1c28428ac0db2c3032 hardcodes the choice for that in the code itself.
      There are checks in mainline that prevent picking a none multiqeue scheduler when queue is multiqueue but not the reverse. If you could pursue the issue of lack of checks with upstream on the block mailing list that would be great.

      Delete
    3. Con Kolivas18 October 2017 at 09:28

      More likely I will just remove the defaulting to BFQ for lack of time to pursue upstream bugs.

      Delete
    4. Anonymous18 October 2017 at 09:42

      If you want to keep it you would need to do as graysky indicated have one default for multiqueue queues and one default for none multiqueue queues and add back the pre merged bfq scheduler under a different name and specify that as the default for none multiqueues. If you do not touch block/Kconfig.iosched then the .config choice is limited to the three elevators that do not trigger the issue but you can still trigger the issue if you specify elevator=bfq on the command line and the system is using a none multiqeue queue.

      Delete
  8. Graysky18 October 2017 at 21:52

    To be clear, credit for that info should go to loqs: https://bbs.archlinux.org/viewtopic.php?pid=1743312#p1743312

    ReplyDelete
  9. Quick Silver9116 November 2017 at 08:29

    Hacking Bitcoin with scripting https://www.youtube.com/watch?v=OHnlkRW98uE&t

    ReplyDelete
  10. Антон Губарьков5 December 2017 at 19:28

    Hello, CK.
    I noticed recently that my SD card reader RT5227 driven by RTSX_PCI stopped working. The card insertion causes
    Dec 04 09:01:56 localhost kernel: mmc0: cannot verify signal voltage switch
    Dec 04 09:01:56 localhost kernel: mmc0: new ultra high speed SDR50 SDXC card at address 59b4
    Dec 04 09:01:56 localhost kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000014
    Dec 04 09:01:56 localhost kernel: IP: blk_mq_init_sched+0x32/0x150


    I run -ck patch set on 4.13. A matching gentoo patch set for 4.13 allows RTSX-PCI work ok. OOPS doesn't fit here - so https://pastebin.com/Gp01dBdR

    ReplyDelete