smeuletz (alexsmeu.delete@this.yahoo.com) on January 6, 2020 1:08 am wrote:
> If some API call is just garbage,
> and not doing what it claims to do, because the world changed in the meanwhile, then document it
> properly or even deprecate it.

If we're talking about sched_yield, the man page says

Avoid calling sched_yield() unnecessarily or inappropriately (e.g., when
resources needed by other schedulable threads are still held by the
caller), since doing so will result in unnecessary context switches,
which will degrade system performance.

sched_yield() is intended for use with real-time scheduling policies
(i.e., SCHED_FIFO or SCHED_RR). Use of sched_yield() with
nondeterministic scheduling policies such as SCHED_OTHER is
unspecified and very likely means your application design is broken.

That's in line with what I've seen Linus say. If you're referring to another API call, please raise the issue with specifics so people can address it and make things better.

> Instead of swearing ...

I don't see any swearing or name calling from either side. The tone may be a bit harsh, I agree. But that tends to come out on forums once in a while (and is nowhere near as bad as it could be). I suggest looking past it and focusing on the facts/arguments being discussed.

> Linus Torvalds and the kernel developers should get some order in there, do some cleanup, properly document
> API calls, deprecate ones that are garbage as stated above

That's not an actionable request because it doesn't have specifics. If you want something changed, it's best to state exactly what you want done so there can be proper discussion and follow up action. Vaguely calling something garbage without specific, actionable criticism doesn't help anyone.

> and add some stable release procedure so that
> you don't need to update your kernel every day on your mainstream linux system.

For the most part, release procedures are the responsibility of distro maintainers, unless you compile your own kernel. If you have an issue with the release process, I think distro maintainers would be better suited to address those concerns.

> Now those are "bad, simplistic
> or incorrect" things, not somebody using your API according your not updated documentation.

Alright, the main issue summarized here is:
-Games are using spinlocks
-A game dev hit an issue with spinlocks causing stutters under linux but not windows (pc/xbox) or freebsd (ps4)
-Linus advocates avoiding spinlocks

Some other notes:
-The original issue was fixed by using mutexes instead of spinlocks
-Mutexes outperform spinlocks on both Linux and Windows, according to the original blog post, in terms of "idle time" (the actual issue the dev faced at work)
-The original blog post says "I hope to have convinced you to avoid spinlocks, even for very short sections." So Linus and the blog post author aren't even disagreeing on that point.
-The blog post author tested on the Ryzen 1700. Core to core latency is high on that chip compared to Intel or later AMD CPUs, so the problem might be exaggerated.