Friday 21 October 2016

linux-4.8-ck2, MuQSS version 0.114

Announcing an updated version, and the first -ck release with MuQSS as the scheduler, officially retiring BFS from further development, in line with the diminished rate of bug reports with MuQSS. It is clear that the little attention BFS had received over the years apart from rushed synchronisation with mainline had cause a number of bugs to creep in and MuQSS is basically a rewritten evolution of the same code so it makes no sense to maintain both.

http://ck.kolivas.org/patches/4.0/4.8/4.8-ck2/

MuQSS version 0.114 by itself:

4.8-sched-MuQSS_114.patch

Git tree includes branches for MuQSS and -ck:

https://github.com/ckolivas/linux

In addition to the most up to date version of MuQSS replacing BFS, this is the first release with BFQ included. It is configurable and is set by default in -ck though it is entirely optional.

The MuQSS changes since 112 are as follows:
- Added cacheline alignment to atomic variables courtesy of Holger Hoffstätte
- Fixed PPC build courtesy of Serge Belyshev.
- Implemented wake lists for separate CPU packages.
- Send hotplug threads to CPUs even if they're not alive yet since they'll be enabling them.
- Build fixes for uniprocessor.
- A substantial revamp of the sub-tick process accounting, decreasing the number of variables used, simplifying the code, and increasing the resolution to nanosecond accounting. Now even tasks that run for less than 100us will not escape visible accounting.

This release should bring slightly better performance, more so on multi-cpu machines, and fairer accounting/latency.

Enjoy!
お楽しみ下さい
-ck
Posted by at
Labels: , , , , , , , ,

17 comments:

  1. zar21 October 2016 at 12:48

    By multi-cpu machines do you mean multi-core with 8 cores and 16 hyperthreads, or machines with more than one die installed?

    ReplyDelete
    Replies
    1. ck21 October 2016 at 12:48

      Multiple packages rather than multicore machines.

      Delete
  2. jwh721 October 2016 at 15:44

    Thanks Con! I have 4.8.3 MuQSS v114 built and running for both x86 SMP and i686 noSMP with BFQ v8r4; no problems so far. Finally used localmodconfig so my build times are down to a half hour (from 2.5; package size is also ~1/5).

    ReplyDelete
  3. Saren21 October 2016 at 19:01

    Hi, I am using a system with haswell cpu.
    4.8+ ck/ck2 does not work well with muqss 112, 114, bfs is ok.
    4.7.8 with muqss 112 however is fine.

    ReplyDelete
    Replies
    1. ck21 October 2016 at 19:15

      Define "does not work well."

      Delete
    2. Saren21 October 2016 at 20:14

      It is stuck at "Loading initial ramdisk" and nothing more.

      BTW 4.7.9 with muqss 114 however is fine too.

      Delete
    3. Saren21 October 2016 at 20:16

      I can't even get systemd loading, so no error messages can be retrived, no tty. It just freezes at "Loading initial ramdisk" .

      Delete
    4. ck21 October 2016 at 21:23

      So your problem is 4.8, not muqss? Muqss on 4.7 is only trivially different to 4.8.

      Delete
    5. Saren21 October 2016 at 21:45

      4.8.3-ck2 with BFS is fine, with MuQSS isn't, so probably.

      Delete
  4. DerVerruckteFuchs21 October 2016 at 20:11

    Trying to run mpd locks up 4.8.2 and 4.8.3 for me on my Haswell machine. On 4.8.2 it's an instant lock up, no tty, no route to the ssh host, nothing is usable. On 4.8.3 it gets weirder, my shell does not start in new terminal windows, in already open terminal windows commands inputted post-mpd act like they hang indefinitely(unlaunched/dead shell like the others?), trying to log in via ssh seems to hang indefinitely, and finally everything is frozen. The attempted ssh connection still hangs afterwards, and no means of getting into a tty either.

    ReplyDelete
  5. Holger Hoffstätte22 October 2016 at 00:22

    No problems with muqss-114 on either 4.8.3 or 4.8.4-rc1 (running as we speak). I'm using intel_pstate everywhere though, so maybe that plays a role (vs. schedutil and all the weird bugs still in mainline).
    The super-fine accounting certainly seems to have an effect on top utilization; ffmpeg now reaches 800% (which seems a tad much, compared to ~790% previously) and a completely idle system was previously measured as 0%, whereas now I have a frequent 1% utilization, probably because the snmpd measures itself and rounds up the now accurately measured values. Or something went wrong in the conversion to µs/jiffies.

    ReplyDelete
    Replies
    1. Holger Hoffstätte22 October 2016 at 10:45

      The nanosecond accounting indeed seems to be a bit too fine-grained. For kicks I switched to CFS and an idle machine is indeed idle; neither user space apps nor kthreads show up as fluttery 1%-ers.

      Delete
    2. ck22 October 2016 at 10:47

      You're assuming cfs is accurate to subtick resolution which it is NOT. If cpu load goes up to 1% then it has been hovering at below this for a few ticks in a row and then has accumulated enough to finally register at the resolution and frequency of 'top'.

      Delete
  6. Anonymous22 October 2016 at 07:03

    @ck:
    There really seems to be an issue with 114, on my 4.7.9 "full combo" shown as not wanting to hibernate via TOI any more.
    From my last known good until 114, that was 112+X, I've cherry-picked one commit to revert: 2460840c... and system is working fine again.
    Please, have a look on it again and re-think the reversion.
    (Of course I got a one-time dmesg warning at boot after removal of that one commit (newer commits rely on the latter)). For completeness, I've put the warning here: http://pastebin.com/NiUS98CQ

    Looking forward to a more serious improvement, and
    BR, as always, Manuel Krause

    ReplyDelete
    Replies
    1. ck22 October 2016 at 07:10

      Thanks Manuel, that actually helps a lot.

      Delete
    2. ck22 October 2016 at 09:58

      You can try git 4.8-muqss branch again to see if it's fixed now.

      Delete
  7. kernelOfTruth22 October 2016 at 07:15

    No problems on Haswell here (E-1245 V3) with 4.8.3

    cpu load is around 0.02 with one instance of audacious playing MP3 music

    Thanks

    ReplyDelete

Subscribe to: Post Comments (Atom)