Another push for sched

Another push for sched_ext

Posted May 13, 2024 15:15 UTC (Mon) by Wol (subscriber, #4433)
In reply to: Another push for sched_ext by pizza
Parent article: Another push for sched_ext

Are you sure?

I'm running stock Excel on stock Windows. Response times are absolute shite - to the point that we are in danger of it taking longer to run than the time available.

(Crap choice of software, I know. Not my choice.)

The most likely response from the vendors I know of is "ask the community".

But the point is, you're all coming up with POSSIBLE excuses for the vendor. What happens when the vendor's recommended, supported environment is "not fit for the purpose intended" to quote UK legalese? ESPECIALLY if said environment contains obvious flaws (not necessarily the vendor's fault) that would help you massively if they were fixed.

That was the complaint with ext4 years ago. That's the complaint with ext_sched now. That's the complaint with Rust. There are people who are actively obstructing attempts to improve Linux, because all they can see is their personal downside.

Are they Luddites? I don't know, I sincerely hope not. After all, the true Luddites could see the benefits of the technology they destroyed - that's why they destroyed it, because they could see the benefits would go to others, not them.

Cheers,
Wol

to post comments

Another push for sched_ext

Posted May 13, 2024 16:49 UTC (Mon) by pizza (subscriber, #46) [Link] (4 responses)

> The most likely response from the vendors I know of is "ask the community".

The fact that the vendors you know are universally crappy doesn't change whose obligation it is to provide support.

Again, $user has a *commercial* relationship with $vendor. $user has no such relationship with "the community", which made $user zero promises, received zero compensation, and thus has precisely zero legal or moral obligation to give $user the time of day, much less provide support for a product they had nothing to do with.

Another push for sched_ext

Posted May 13, 2024 17:08 UTC (Mon) by mb (subscriber, #50428) [Link] (3 responses)

Yes. All correct.
Yet, the users will spam the community mailing lists, because that's the next logical step for them, if the vendor refuses support.

Why should we merge a feature that doesn't benefit the community?
If sched_ext benefits the community, I'm all for it. If not, why can't the exceptional use cases just ship a patched kernel?

Another push for sched_ext

Posted May 13, 2024 17:30 UTC (Mon) by pizza (subscriber, #46) [Link]

> Yet, the users will spam the community mailing lists, because that's the next logical step for them, if the vendor refuses support.

Yep. And that's what $vendors are counting on as it lets them save money on knowledgeable support staff.

(Mind you, user support request to vendors are not necessarily reasonable. After all, you wouldn't expect a company that makes hammers to "support" a customer complaining that the structure they are building keeps falling apart)

> Why should we merge a feature that doesn't benefit the community?

Every feature benefits someone. Unfortunately every feature also brings along costs that rarely fall onto the same someones that are reaping the benefits.

Those costs can be short term ("performance regression under every other workload") or longer term (technical debt, combinatorial complexity, security vulnerabilities with cutsey names, etc)

Another push for sched_ext

Posted May 13, 2024 22:02 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)

> Yet, the users will spam the community mailing lists, because that's the next logical step for them, if the vendor refuses support.

And? What's new?

> If sched_ext benefits the community, I'm all for it. If not, why can't the exceptional use cases just ship a patched kernel?

Agreed: if sched_ext turns out to be used ONLY by closed-source vendors then it shouldn't be merged. But that seems rather unlikely, doesn't it?

Another push for sched_ext

Posted May 25, 2024 0:16 UTC (Sat) by mrugiero (guest, #153040) [Link]

Maybe the same policy as with DRM drivers should be applied here. Give me some useful BPF programs (not just toy schedulers) that I may be interested in running, and then I may merge the code needed to run them. That's the safe bet, if you require that you already vanished the possibility of those magical cool schedulers never coming to the wider public.