malte skarupke a game developerI publish a comparison of the performance of locks based on Mutex and Spinlock using various task schedulers. The tests showed abnormally delays lengths when using Spinlock with the default task scheduler on Linux.
The author of the tests concluded that the Linux task scheduler has problems that affect negatively the work of games created for the Google Stadia service, where games run on the GPU in a cloud environment and the client only streams screen content up to 60 frames per second.
In such conditions, it is necessary to ensure the timely display of the frames on the screen, and delays of more than one millisecond are noted.
Linus Torvalds joined in the discussion of the evidence, who called it "pure garbage." and an example of how to obtain indicators that do not reflect the real reality without fully understanding the subject.
Torvalds wrote:
The whole post appears to be wrong and is measuring something completely different from what the author thinks and claims he is measuring.
First of all, spinlocks can only be used if you really know that you are not programmed while using them ... Basically it reads the time before releasing the lock, and then it reads it after re-acquiring the lock, and it states that the time is the difference is the time when the lock was not maintained. Which is stupid and useless and completely wrong.
That is pure rubbish.
Spinlock is a low-level primitive that must be used in the user space with great care and fully understand the details; otherwise, you can get what the tester demonstrated.
Linus advised game developers not to use spinlock and that they do not try to block their own blocking systems based on it, rather use existing proven mechanisms to inform the system that they are waiting for the lock to be released to eliminate the influence of the programmer.
Spinlock-based plugins can be used only with full confidence that the programmer will not interrupt their execution. The spinlock-based locks used in the tests are implemented through a homemade binding that works in user space.
The task scheduler can take control at any time during the execution of this link and switch to another task.
Given whate performance measurement is based on absolute timer values, defined delays in the tests they cover not only the delays in the controller blocking, but also the code that was run in a different context, that is to say.
It not only measures what the tester tried to measure, but also the "noise" from other calculations in the system.
The problem is that developers shouldn't have been using spinlocks in the first placer, as far as, It was not the Linux programmer to blame, but the developers' approaches to using it.
The author of the test tried to object to Linus, noting that the use of proprietary spinlock-based locking systems is often used in practice in games, since when using simpler programmers than on Linux, tests show better performance.
Linus mentioned that the Linux scheduler is universal, refined for decades and optimized not only for the desktop and the games, but also for other types of loads work, for example, server systems and therefore takes into account many nuances when planning tasks.
Add specific optimizations that will reduce latency in games Google Stadia may increase the responsiveness in a particular case, but it is likely to reduce the overall performance of the programmer.
For example, Windows Scheduler performs better in the tests under discussion as it is much simpler than Linux Scheduler and is primarily optimized for specific desktop tasks.
Source: https://probablydance.com/