smeuletz (alexsmeu.delete@this.yahoo.com) on January 6, 2020 9:11 am wrote:
> Well, in his post Linus Torvalds himself says: "End result: sched_yield() is basically historical garbage"
> So, since it rarely has any good use, and can only be used with a realtime scheduler, it should
> be deprecated and later removed and a new header (eg: sched_realtime.h) should be added, with a
> new sched_realtime_yield() API, which would return error if the scheduler is not realtime.
> And thus, the API would be updated to reflect reality and minimize the chance for erroneous usage.

I actually don't disagree with that at all from a technical standpoint. It really should be much harder to use sched_yield() than it is, because it really is almost always the wrong thing.

But the kernel doesn't actually control the standards bodies, and sched_yield() really is a standard interface, even if it's not a good one any more. It's a standard interface because of various historical reasons, and historically it actually did make sense (and as mentioned, it can make sense in very limited situations still today).

It's just that the kinds of situations - and the kinds of hardware issues - where people use it today are not where it came from. The workloads have gotten a lot more complex over the decades, and a simple "yield my timeslice" used to make more sense, because that was a much simpler world. People didn't do per-cpu scheduling decisions back then even if they did SMP at all.

In fact, that's probably also why it worked so well on Windows originally. Windows SMP simply isn't where Linux is.

And yes, we could add a warning inside the kernel when it is actually used in non-RT context, and we do things like that for some seriously dubious usage. But since users generally can't do much about random binaries doing odd things, we try to limit that only to truly serious issues, not "your performance will be random".

Maybe this discussion ended up at least making more people aware of this all..

Linus