Linus responds to developer criticism of problems with Linux Scheduler

A few days ago, a game developer using C ++, Malte Skarupke, posted a blog saying that he encountered problems in providing Linux games for Google’s cloud gaming service platform, Google Stadia, and stated that the problem apparently came from the Linux kernel scheduler, especially Spinlock in the Linux kernel.

Malte pointed out: “I found that most mutex implementations are really good, that most spinlock implementations are pretty bad, and that the Linux scheduler is OK but far from ideal. The most popular replacement, the MuQSS scheduler has other problems instead. (the Windows scheduler is pretty good though).”

Linus Torvalds also commented on this Malte article. In the process of communication, although Linus did not agree with the point of view of the article, his words were no longer so intense. Linus Torvalds wrote:

The whole post seems to be just wrong, and is measuring something completely different than what the author thinks and claims it is measuring.

First off, spinlocks can only be used if you actually know you’re not being scheduled while using them. But the blog post author seems to be implementing his own spinlocks in user space with no regard for whether the lock user might be scheduled or not. And the code used for the claimed “lock not held” timing is complete garbage.

It basically reads the time before releasing the lock, and then it reads it after acquiring the lock again, and claims that the time difference is the time when no lock was held. Which is just inane and pointless and completely wrong.

So now you still hold the lock, but you got scheduled away from the CPU, because you had used up your time slice. The “current time” you read is basically now stale, and has nothing to do with the (future) time when you are actually going to release the lock.

Somebody else comes in and wants that “spinlock”, and that somebody will now spin for a long while, since nobody is releasing it – it’s still held by that other thread entirely that was just scheduled out. At some point, the scheduler says “ok, now you’ve used your time slice”, and schedules the original thread, and now the lock is actually released. Then another thread comes in, gets the lock again, and then it looks at the time and says “oh, a long time passed without the lock being held at all”.

For more interesting technical details, see the full article by Linus.