Wednesday 10 June 2020

linux-5.7-ck1, MuQSS version 0.202 for linux-5.7

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

linux-5.7-ck1:
-ck1 patch:
Git tree:
MuQSS only:
Download:
Git tree:
Web: http://kernel.kolivas.org

This release is a minor bugfix and resync from 5.6-ck2.
Enjoy!
お楽しみ下さい
-ck

Posted by at
Labels: , ,

42 comments:

  1. Anonymous11 June 2020 at 01:44

    Thank you very much.

    ReplyDelete
  2. Anonymous11 June 2020 at 04:10

    Hi CK. I am getting this error when building. Did you miss a resync?

    ...
    GEN .version
    CHK include/generated/compile.h
    LD vmlinux.o
    MODPOST vmlinux.o
    MODINFO modules.builtin.modinfo
    GEN modules.builtin
    LD .tmp_vmlinux.btf
    ld: drivers/thermal/cpufreq_cooling.o: in function `cpufreq_set_cur_state':
    /scratch/linux-ck/src/linux-5.7.1/drivers/thermal/cpufreq_cooling.c:458: undefined reference to `arch_set_thermal_pressure'
    BTF .btf.vmlinux.bin.o
    tag__check_id_drift: subroutine_type id drift, core_id: 1129, btf_type_id: 1127, type_id_off: 0
    libbpf: Unsupported BTF_KIND:0
    btf_elf__encode: btf__new failed!
    free(): double free detected in tcache 2
    scripts/link-vmlinux.sh: line 114: 3291862 Aborted (core dumped) LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1}
    LD .tmp_vmlinux.kallsyms1
    .btf.vmlinux.bin.o: file not recognized: file format not recognized
    make: *** [Makefile:1117: vmlinux] Error 1

    ReplyDelete
    Replies
    1. Con Kolivas11 June 2020 at 07:27

      Config?

      Delete
    2. Anonymous11 June 2020 at 10:34

      https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux

      Delete
    3. Con Kolivas11 June 2020 at 21:50

      Thanks. I'm not sure if you use git, but I've pushed a simple fix for that build issue to the git tree for both muqss and -ck.

      Delete
    4. graysky12 June 2020 at 00:43

      Thanks, CK. I applied that patch and the build completed successfully.

      https://aur.archlinux.org/cgit/aur.git/commit/?h=linux-ck&id=2b6a356337429a433f3cc364ed071a8d29e44397

      Delete
  3. graysky11 June 2020 at 20:34

    CK - Is cpufreq_cooling.c missing that function as suggested by several users of the linux-ck package?

    https://gitlab.com/alfredchen/linux-bmq/-/commit/ad9eb862e06f395e846a2f2e084e5b0e7eb9ca4b

    ReplyDelete
  4. Anonymous11 June 2020 at 20:54

    Thank you for the update. No issues here.

    ReplyDelete
  5. fidaj17 June 2020 at 02:34

    This comment has been removed by the author.

    ReplyDelete
  6. sirspudd19 June 2020 at 10:45

    Hola Con; thank you for your work

    Would you expect isolcpus to work against this muqss release?

    isolcpus=11-14,27-30 nohz_full=11-14,27-30 rcu_nocbs=11-14,27-30

    carves a hole in my resources when using a stock kernel, but I am not seeing the same scheduling hole when using 5.7-ck.

    ReplyDelete
    Replies
    1. Con Kolivas19 June 2020 at 10:53

      Probably not. I haven't paid much attention to enterprisey features short of making them compile in when demanded by userspace.

      Delete
    2. damentz23 June 2020 at 23:17

      Hi Con, what about adding stubs for setting cfs_quota_us for docker? I got an issue recently for Liquorix that Pterodactyl doesn't start with MuQSS. The software tries to always set cfs_quota_us even if it doesn't exist:

      https://github.com/damentz/liquorix-package/issues/34

      Delete
  7. Schorsch25 June 2020 at 20:08

    Building 5.7.6 with patch-5.7-ck1 I get:
    error: include/uapi/linux/sched.h: leak CONFIG_SCHED_MUQSS to user-space
    make[6]: *** [scripts/Makefile.headersinst:63: usr/include/linux/sched.h] Error 1
    make[6]: *** Waiting for unfinished jobs....
    make[5]: *** [Makefile:1234: headers] Error 2

    ReplyDelete
    Replies
    1. Schorsch25 June 2020 at 21:21

      Same on building 5.4.49 with patch-5.4-ck1 :(

      Delete
    2. Anonymous26 June 2020 at 03:35

      Didn't test yet myself, but this should fix it:
      https://github.com/zen-kernel/zen-kernel/commit/6aefea555ae66883483540d43c2024acecf61599

      Delete
  8. Schorsch26 June 2020 at 04:13

    I can confirm that
    https://github.com/zen-kernel/zen-kernel/commit/6aefea555ae66883483540d43c2024acecf61599
    fixes the issue. Thanks

    ReplyDelete
  9. Nicola29 June 2020 at 00:42

    With kernel 5.7 I can't suspend my laptop to ram. The suspend procedure gets stuck, the screen goes off but the laptop is not suspended (the fans keeps spinning etc.). A hard reset is necessary. The log stops at:

    giu 28 16:34:24 stryke systemd[1]: Reached target Sleep.
    giu 28 16:34:24 stryke systemd[1]: Starting Suspend...
    giu 28 16:34:24 stryke systemd-sleep[1522]: Suspending system...
    giu 28 16:34:24 stryke kernel: PM: suspend entry (deep)

    With stock kernel it works as expected.
    My system is Archlinux with linux-ck-skylake 5.7.6-2 from graysky's repo-ck.

    ReplyDelete
    Replies
    1. damentz1 July 2020 at 02:35

      Check zen kernel's 5.7/muqss branch here:

      https://github.com/zen-kernel/zen-kernel/commits/5.7/muqss

      It's currently untested, but "muqss: Revert invocation of "finish_cpu" when offlining core" should fix the issue. Worst case, you can revert "sched/core: Fix illegal RCU from offline CPUs" entirely.

      Delete
    2. Nicola1 July 2020 at 04:06

      Thanks, but I'm not very comfortable in patching&building the kernel. In any case, if these are known regressions then are they going to be fixed in mainline ck patchset? If yes then I'll simply wait for a new release.

      Delete
    3. damentz1 July 2020 at 05:55

      That's up to Con. I'll revisit this thread once I release a new update to Liquorix and let you know if the patch solves the issue.

      And like I mentioned, you can just straight up revert the commit that introduced the bug. That's the easiest and most straightforward change that fixes suspend.

      Delete
    4. damentz2 July 2020 at 02:25

      I released a new Liquorix kernel today for 5.7.7, the updated workaround that reverts the invocation for finish_cpu on MuQSS works. I'm able to suspend and resume without a hitch.

      Delete
    5. Nicola10 July 2020 at 17:27

      The just released Archlinux linux-ck 5.7.8-1 incorporates the patch and fixes suspend to ram and resume. Thanks to damentz and graysky.

      Delete
  10. Anonymous1 July 2020 at 00:44

    Same here with Arch Linux and kernel 5.7; laptop is not able to resume from suspend. There is nothing in logs.

    ReplyDelete
    Replies
    1. damentz1 July 2020 at 02:35

      Check zen kernel's 5.7/muqss branch here:

      https://github.com/zen-kernel/zen-kernel/commits/5.7/muqss

      It's currently untested, but "muqss: Revert invocation of "finish_cpu" when offlining core" should fix the issue. Worst case, you can revert "sched/core: Fix illegal RCU from offline CPUs" entirely.

      Delete
  11. Sveinar Søpler19 July 2020 at 01:23

    When compiling kernel with MuQSS using "make bindeb-pkg", this generates an error saying that using CONFIG_ statements in UAPI leaks to user-space.
    Ref. https://github.com/torvalds/linux/commit/5967577

    This means that "checks" for kernel config settings should be avoided in include/uapi/linux/sched.h

    https://github.com/ckolivas/linux/commit/865f9eb66384311dc3bb6c79cfd34d841f6e0b18#diff-4fdf2eda03ab03c466f4e23fc5c80555L115-L121

    Is it "good enough" to just skip the checks and do the #defines regardless of using MuQSS? What would be the implications of defining eg. SCHED_ISO on a regular CFS scheduler build?

    It might be a better way to do this perhaps.. moving the defines to a different include file maybe? Thoughts?

    ReplyDelete
    Replies
    1. Anonymous19 July 2020 at 19:55

      Did you notice the patch from zen kernel that was mentioned above?

      https://github.com/zen-kernel/zen-kernel/commit/6aefea555ae66883483540d43c2024acecf61599

      Delete
    2. Sveinar Søpler19 July 2020 at 21:21

      Yeah, but adding this to an "ignore list" is probably not the right thing to do, since the upstream kernel patch specifically mentions:
      Misuse of CONFIG_* in UAPI headers should result in an error.

      So, doing this "check" in the UAPI header, is a misuse..

      What is more correct? Bypassing the check by adding sched.h to a "ignore checking" list, or doing something else?

      Delete
    3. Sveinar Søpler19 July 2020 at 22:00

      This is actually just a problem if you intend to add the MuQSS/ck patchset, and decides to use CFS scheduler, as you could not (cleanly) add eg. BMQ/prjc scheduler TOGETHER with MuQSS/ck anyway..

      Is it a regular occurrence to add the patchset and still use CFS? (Since its not a boot option to change, it would be mostly pointless to do so).

      Is it "wrong" to just do the #define statements regardless of #ifdef CONFIG_SCHED_MUQSS, since you would most likely (although not required) use it with the patchset?

      Delete
  12. Ali3 August 2020 at 06:10

    still are u doctor? are u going to hospital every day or you are just coding?

    ReplyDelete
    Replies
    1. Con Kolivas3 August 2020 at 08:20

      I'm not practising medicine any more.

      Delete
    2. Ali4 August 2020 at 08:29

      why did u leave it?And at which age did u left? I am 18 years old and i couldnt deciede which one is better option, medicine or computer science, i am scared of ageism in CS, what do you think about this? thx

      Delete
    3. Con Kolivas4 August 2020 at 08:39

      Medicine is definitely the more reliable career, but no point doing something you don't like. I did enjoy my career greatly when I was doing it but I left after 25 years in medicine because I got sick of the hospital system.

      Delete
    4. Ali4 August 2020 at 21:12

      which one was more enjoyable for you? Computer science or Medicine?

      Delete
    5. asdf5 October 2020 at 09:34

      did you use drugs? ;D

      Delete
  13. Anonymous8 August 2020 at 04:02

    Hi Con,

    Would there be any detrimental effect to re-enabling the cpuacct cgroup? I don't need its functionality, though some programs are expecting it to exist.

    ReplyDelete
  14. Unknown9 August 2020 at 06:12

    It would appear that ck1 does not apply cleanly to 5.7.14 :/ Will there be a 5.8 patch?

    ReplyDelete
    Replies
    1. Anonymous9 August 2020 at 15:55

      e.g. this patch from linux-ck Arch linux package by graysky can be applied to the patch-5.7-ck1 to make it work with 5.7.14

      https://aur.archlinux.org/cgit/aur.git/tree/fix_ck1_for_5.7.14.patch?h=linux-ck

      Delete
    2. Con Kolivas9 August 2020 at 16:05

      There'll be a 5.8 patch when I eventually get around to it.

      Delete
    3. R.X.O.M.12 August 2020 at 03:13

      Getting it to apply was trivial: the failing hunk is the insertion of an #include statement that no longer applies because upstream added an #include at that exact location too.

      Delete
  15. R.X.O.M.12 August 2020 at 03:18

    About the patched 5.7.14-ck1 kernel: it makes me *log in* to a black desktop with just a mouse cursor on 2 of my systems, Cherrytrail (N3150) and Baytrail (some Atom) based. Disabling the compositor in KDE's KWin makes the content of certain windows appear so it must have something to do with accelerated graphics. The same install booting another laptop with an i3 gives me perfectly normal graphics.

    I strongly doubt this can be related to the ck1 patch; is anyone here aware of known regressions in the i915 driver?

    BTW: thanks for the above tips on how to fix the build failure and fix S2RAM!

    ReplyDelete
  16. Anonymous23 August 2020 at 22:01

    Once again, linux-5.7-ck1 doesn't apply cleanly against 5.7.17.

    To fix this, first apply the following to patch-5.7-ck1 (in addition to the 5.7.14 fix mentioned on a post above): https://pastebin.com/uMMJJq3y

    Then apply this to fix the build: https://github.com/zen-kernel/zen-kernel/commit/e7113f2c1d56962d4afabc627ad761c138f5b858

    ReplyDelete

Subscribe to: Post Comments (Atom)