He states (paraphrasing) - it's undefined because there's no real way (unless in a realtime scheduler) to find what to yield to without instigating complexity.

The search itself is the quest that the kernel would rather not do at all. Step 3 is undefined and thus sched_yield itself is undefined.

So let's look over our cores:

6 of them are churning through processes that do nothing but call sched_yield. Nothing has been waiting to run for more than 3 microseconds.

2 of them are doing real work, and the benchmark threads that happen to be on the same core have been waiting to run for most of a millisecond.

If you're stuck, then B is one of the processes that has been waiting.

So the obvious change would be to move threads around in sched_yield. Then B will get scheduled within microseconds.

What's your CPU use right now? I bet it's less than 200%. Or will be if you exclude your web browser.

The typical background process is active far less than one percent of the time.

Right, but you would expect the "switch to another thread" function to eventually pick the one that's sitting there with a growing and growing time since it last got a chance to run.

It would be easy to guarantee that if any thread has been waiting for at least x amount of time, then any context switch without long-waiting local threads will pick that thread. (If it's on the same NUMA node, at least.) But in the actual implementation that time can build up to a huge amount with no effect, even as thousands of yield calls go by.

> Especially not if that process is soft locked to a different core.

Yeah, that's the problem, it's getting locked to a core even though other cores are desperate for threads to run.

Pipes have a small buffer. Once it's full, the caller will block, and the scheduler will know precisely what to schedule to unblock it.

What about just temporarily increasing the process' nice value?

That should be simple to do, and the scheduler already knows how to yield to processes with lower nice values.