Another push for sched_ext

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

> 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.