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.
MuQSS version 0.114 by itself:
Git tree includes branches for MuQSS and -ck:
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.
By multi-cpu machines do you mean multi-core with 8 cores and 16 hyperthreads, or machines with more than one die installed?ReplyDelete
Multiple packages rather than multicore machines.Delete
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
Hi, I am using a system with haswell cpu.ReplyDelete
4.8+ ck/ck2 does not work well with muqss 112, 114, bfs is ok.
4.7.8 with muqss 112 however is fine.
Define "does not work well."Delete
It is stuck at "Loading initial ramdisk" and nothing more.Delete
BTW 4.7.9 with muqss 114 however is fine too.
I can't even get systemd loading, so no error messages can be retrived, no tty. It just freezes at "Loading initial ramdisk" .Delete
So your problem is 4.8, not muqss? Muqss on 4.7 is only trivially different to 4.8.Delete
4.8.3-ck2 with BFS is fine, with MuQSS isn't, so probably.Delete
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
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).ReplyDelete
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.
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
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
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
Thanks Manuel, that actually helps a lot.Delete
You can try git 4.8-muqss branch again to see if it's fixed now.Delete
No problems on Haswell here (E-1245 V3) with 4.8.3ReplyDelete
cpu load is around 0.02 with one instance of audacious playing MP3 music