Monday, 31 December 2018

linux-4.20-ck1, MuQSS version 0.185 for linux-4.20

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

linux-4.20-ck1:
-ck1 patches:
Git tree:
MuQSS only:
Download:
Git tree:


Web: http://kernel.kolivas.org


In addition to a resync from 4.19-ck1 I've extended the runqueue sharing options to all CPUs as well, meaning it can be used in NUMA hardware as a single runqueue if desired.

Merry Christmas, and have a happy new year everyone. May your new year be filled with good health, stable kernels, and more bitcoin adoption and value.

Enjoy!
お楽しみ下さい
-ck

30 comments:

  1. Thanks so much.
    Perfect way to start into the new year.
    Happy New Year!

    ReplyDelete
  2. Damnit, I love you Con. Happy new year

    ReplyDelete
  3. ooo, good, thx for new ver Con<3

    ReplyDelete
  4. Joyeuse année 2019 et merci de ta persévérance :-)

    What do you think about gnu hurd project ?

    ReplyDelete
  5. Runs great <3.

    ReplyDelete
  6. Hi Con, I'm having a compilation issue. x64 builds fine. But when I try to build for x86, I'm getting the following compile error:
    https://del.dog/mojukeyoqa

    (the 4.19 patch worked fine for x86)

    Thanks for all your work!

    ReplyDelete
    Replies
    1. There are some fixes in git on both the muqss and -ck branch, courtesy of SSB. Try those :)

      Delete
    2. Worked like a charm, thanks again!

      Delete
  7. Hi,

    I'm reporting this here as it is the current blog item, but is affects all recent MuQSS and kernel releases. I've observed it since kernel version 4.17, when I introduced encryption for my main workstation. I'm using LUKS (linux unified key setup) and the system is configured to read the pass codes from the console relatively early during kernel boot.

    With the vanilla kernel it works as designed. However, as soon as I compile in MuQSS, all key presses sort of "bounce". In other words each key press results in any number of characters being generated, making the blind input of key phrases impossible. I have not been able to use MuQSS since then.

    Any ideas how I could fix it?

    Thanks

    ReplyDelete
    Replies
    1. I used to have this issue too, it was probably solved by enabling periodic timer ticks - CONFIG_HZ_PERIODIC=y . A workaround was to use a USB keyboard. But it was really long ago and it's hard to recall the details, my current muqss config just does not exhibit this issue.

      Delete
    2. Config for 4.14 which does not exhibit the issue:

      https://drive.google.com/file/d/1k4hHglg-gdPOJMGK-s3gfGwCfwmnld1K/view?usp=sharing

      Hope that helps.

      Delete
    3. Thank you a lot. The timer tick option did the trick. I'm back on MuQSS. ^_^
      It still means that there is some underlying issue preventing me from using MuQSS should the kernel ever go tickless.

      Delete
    4. Were you using MuQSS alone or with the rest of the -ck patches?

      Delete
    5. The issue being solved with periodic ticks does not surprise me actually. Ran into a different issue with MuQSS and the (default) idle dynticks.

      Some audio distortion in WINE that I eventually solved by recompiling the kernel with full periodic ticks.

      This was with just MuQSS, sans -ck.

      The kernel will probably eventually go full tickless by default, so whatever the underlying problem may be, it does need to be addressed.

      Delete
    6. As people (or is it person?) keep repeating ad nauseam. Perhaps the ck patches should become part of muqss since muqss is intrinsically a tickless scheduler and relies on highres timeouts to work properly, but unfortunately the highres timers in mainline are stupidly tick resolution limited...

      Delete
    7. No offense was implied, no need to infer any either.

      Delete
    8. to answer the earlier question, I have been applying the pure MuQSS patch, no other kernel patches. Also I'd like to clarify, I have no deep insight in kernel development. I just picked the rumour up here...

      Delete
  8. Smooth as silk. Partially because of the low level VLA work on 4.20 itself and the rest is MuQSS' doing.

    Great work as always. Amazing job on including NUMA nodes in the single runqueue option.

    ReplyDelete
    Replies
    1. I agree.
      Great job and smooth AF 4.20.1.
      Thanks.

      Delete
  9. Hi all, I was wondering if other people are seeing a 'psi: task underflow!' message when booting 4.20-1 linux-ck kernel?
    More info on psi (pressure stall information for CPU, memory, and IO): https://lwn.net/Articles/763629/

    When adding 'psi=0' kernel parameter to effectively disable psi, this message goes away. Alas my experience with/knowledge of psi is lacking, so I cannot judge if this is a wise thing to do, or at all related to linux-ck or MuQSS...

    $ pacman -Q linux-ck-core2
    linux-ck-core2 4.20-1

    dmesg snippet:
    ...
    [ 0.509321] MuQSS locality CPU 0 to 1: 2
    [ 0.509323] Sharing MC runqueue from CPU 1 to CPU 0
    [ 0.509327] CPU 0 RQ order 0 RQ 1
    [ 0.509328] CPU 1 RQ order 0 RQ 1
    [ 0.509329] CPU 0 CPU order 0 RQ 0
    [ 0.509331] CPU 0 CPU order 1 RQ 1
    [ 0.509332] CPU 1 CPU order 0 RQ 1
    [ 0.509333] CPU 1 CPU order 1 RQ 0
    [ 0.509334] MuQSS runqueue share type MC total runqueues: 1
    [ 0.509542] psi: task underflow! cpu=0 t=2 tasks=[0 0 0] clear=4 set=0
    ...

    full dmesg: https://ptpb.pw/xwAE.log

    ReplyDelete
    Replies
    1. PSI support is new on MuQSS and completely untested at this stage and probably broken. That said, it's a debugging feature that you won't be using so there's not much point enabling it.

      Delete
    2. Thanks for clearing that up so quickly!

      Delete
    3. > it's a debugging feature

      It isn't. Or, it is, but to the same extent as loadavg.

      Delete
    4. Whereas it may not be a literal debugging feature in the strictest sense of the word, it is a feature that is most commonly used by and most commonly useful for developers.

      That does make its use case mostly of a debugging nature.

      Delete
  10. Hi Con,

    First of all, thank you for your continuous work with the patchset.

    I have a question about using the 'workqueue.power_efficient' kernel boot parameter, which can be used to disable per-cpu workqueues in order to improve power efficiency, and how it relates to the runqueue sharing in MuQSS.

    I understand these are two different things, but I'm curious whether the per-cpu workqueues should work in any way differently with MuQSS compared to vanilla kernel, that should be taken into consideration with the kernel configuration.

    Do you have any thoughts or recommendations about using the workqueue.power_efficient option with MuQSS enabled kernel?

    Thank you again, and I hope you'll have a great year.

    ReplyDelete
    Replies
    1. It should just work the same as in vanilla, though I have no informed opinion on its usage as such.

      Delete
    2. Thanks for the clarification.

      Delete
  11. Replies
    1. No, docker and containers that use CPU scheduler cgroups in general do not work at all with MuQSS. There is no 'containment' as such, and the cgroups are only there to allow systems to run that mandate their existence.

      Delete
    2. Which is a good thing imho.

      Delete