Tuesday, 12 March 2019

linux-5.0-ck1, MuQSS version 0.190 for linux-5.0

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

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


Web: http://kernel.kolivas.org


This is mostly a resync from 4.20-ck1 with a minor tweak to CPU ordering for slightly better throughput. Note that BFQ and I/O schedulers have nothing to do with MuQSS or any of the -ck code so the changes to I/O schedulers in mainline are of no consequence.

Enjoy!
お楽しみ下さい
-ck

15 comments:

  1. Pulled those before the weekend from GIT, and compile/works fine so far for me :)

    Thank you CK!

    ReplyDelete
  2. Thank you, feels a little more responsive. Good job!

    ReplyDelete
  3. Did you ever test your patches against AMD CPUs?

    I have the problem that on (pre-Ryzen) AMD CPUs, the clock speed is always on max with schedutil on the MuQSS patchset...?

    ReplyDelete
    Replies
    1. Seeing the same phenomenon. NO_HZ_IDLE, 100 Hz, MuQSS, schedutil and all 4 cores at max clock 100% of the time.

      With CFS instead of MuQSS, the core clocks behave normally.

      It is almost as if schedutil simply is not functioning with MuQSS, as if 'performance' is active instead.

      Measured with a watch -n1 of cat /proc/cpuinfo over some time.

      Delete
    2. It's likely schedutil broke. No, I don't have any AMD CPUs. Try another governor like ondemand to see if it's just schedutil I broke or something else.

      Delete
    3. OP here:
      Max clock problem is only with schedutil.
      On ondemand clocks are reasonable, however I don't reach max. clocks with ondemand under full load.

      I don't use ondemand normally, so can't tell if this is a problem with the MuQSS patchset or in general.

      Delete
    4. Seeing the same here; other software-based governors functioning as expected, schedutil simply not functioning at all.

      @OP: Regarding ondemand not reaching max clock; unsure what could be going on there. Is 'performance' reaching max clock? Not suggesting that is a viable workaround, mostly just suggesting it to confirm.

      Anyhow... I'd love to be able to donate an AMD CPU to debug this issue but, I have none spare.

      schedutil is so far ahead of its competitors, would be wonderful to see it functioning as expected in conjunction with MuQSS.

      Delete
    5. Was schedutil working properly last -ck release?

      Delete
    6. Actually, never even bothered to take notice of that... but, just recompiled 4.20 with MuQSS and... no, schedutil was broken in 4.20 as well. At least, in conjunction with MuQSS. 100% max clock on all cores, 100% of the time.

      Could go back further but this is an aging PC with a relatively small amount of memory so recompiling a half a dozen kernels is going to take a while.

      So, for now...

      - 5.0, disfunctional
      - 4.20, disfunctional

      Delete
    7. So, as per the OP's report of a broken schedutil on 4.19 as well... hmmm...

      I think we may need a more powerful AMD box to debug this. Just to reduce the compile time; takes me 90+ minutes for a single compile.

      Not enough memory to run it off /dev/shm, sadly. Would drastically reduce it.

      Delete
    8. If you are just building the kernel for quick testing "make localmodconfig" could speed up the process.

      Delete
    9. Thanks for the suggestion but, looked at the numbers and it's just not going to be enough. Best way to go about this would be to go back all the way to 4.7, the kernel that first saw schedutil being implemented.

      Since it cannot be entirely ruled out at this point that schedutil simply never worked correctly in conjunction with MuQSS.

      And I have neither the time nor the hardware to compile that many kernels to manually bisect this phenomenon.

      Delete
  4. OP here:
    I have broken schedutil on 4.19

    ReplyDelete
  5. Thanks Con for maintaining this.

    I've made throughput benchmarks here :
    https://docs.google.com/spreadsheets/d/163U3H-gnVeGopMrHiJLeEY1b7XlvND2yoceKbOvQRm4/edit?usp=sharing

    I've tested ck1 and MuQSS alone, configured with NO_HZ_IDLE and HZ=100.

    Reading one of your comments on the 0.185 announcement, I understand that for low latency 'MuQSS + high res timers' (aka ck1 patchset) is better than MuQSS alone.
    Is that right ?

    I also wanted to update interbench results. Is this benchmark suited to compare different scheduler ?
    From all my tries to benchmark latency, I remember it is tricky to do so due to different system calls implementations.

    Pedro

    ReplyDelete