Happy new decade everyone.
Here's an interesting blogpost a few people on IRC have pointed out to me. Best save reading it for after you've sobered up in the new year ☺
https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is
The anecdotal video performance part of that whole post may well be the most interesting part of it, but there's definitely food for thought there regarding locking primitives and MuQSS's performance. I've pointed out in a comment (yet to be published) to the author that yield is configurable on MuQSS and use of it is likely responsible for the poor performance of the sub-benchmarks involving it. Either way it makes for interesting reading and I anticipate a mainline mutex and especially spinlock performance speed chase in the near future. This can only lead to good things for everyone.
Thanks, you too.
ReplyDeleteInteresting article.
Looking forward to it.
On a side note: It would also be nice to disable the perf subsystem altogether.
I also wish you a happy new decade.
ReplyDeleteIt's nice that people spend time investigating issues like spinlock/mutex performance. Would be interesting to see if the clear linux kernel and glibc patches affect the performance.
glibc:
https://github.com/clearlinux-pkgs/glibc/blob/master/spin-smarter.patch
https://github.com/clearlinux-pkgs/glibc/blob/master/spinaphore.patch
kernel:
https://github.com/clearlinux-pkgs/linux/blob/master/0124-locking-rwsem-spin-faster.patch
It'd sure be nice if the commits had more meat to them. Interesting nonetheless. Most (all?) glibc development is done on Intel CPUs, are there any benchmarks out there for newer families of AMD?
DeleteHi Con,
ReplyDeletethis deadlocks my i5-8600k system while running the SCHED_FIFO tests.
I've changed the SCHED_FIFO priority to 10 in my test because of not having enough privileges.
https://github.com/dwalthour/mutex_test