用 Rust 编写的 Linux 调度器在游戏性能方面显示出令人鼓舞的结果
一个用 Rust 编写并通过 eBPF 接入的 Linux 原型调度器，据称在系统高负载下能提升游戏性能，例如在后台编译内核时。评论者指出，提升来自面向特定工作负载的调度算法和新的 sched_ext 基础设施，而不是 Rust 天生比 C 更快；不过，他们仍认为这有力证明了 Rust 可以处理核心且性能敏感的任务。讨论还强调了可热插拔的用户空间调度器如何带来快速实验能力，同时也反复出现对 Rust 炒作、易用性，以及它在底层系统中替代或补充 C 的角色的争论。
Rust vs C 和性能
- 许多人认为，性能提升来自调度算法和工作负载专门化，而不是 Rust 本身。
- 也有人指出，Rust 仍然可能间接有帮助：更强的安全性和更好的易用性，可能让尝试更复杂或更冒险的算法时更容易正确实现。
- 文中强调，这样的调度器完全可以用 C（或其他语言）编写，而且 C 也能实现任意复杂的算法。
内核中的 Rust 与 sched_ext/eBPF
- 几条评论强调，真正的故事在于：借助 sched_ext 和 eBPF，可以构建一个核心内核组件，而用户空间部分只是顺带用 Rust 编写的。
- 这个调度器的内核侧部分是用 C 写的；Rust 用于用户空间逻辑。
- 其实已经有其他 sched_ext 调度器，其中一些完全在内核内用 C 实现，还有一些使用用户空间 C；它们在某些生产负载上优于默认调度器。
调度器行为与基准测试
- 展示出来的收益是针对在重负载后台任务（例如内核编译）下玩游戏的场景，而且明确是特定工作负载相关的。
- 有人认为这对于一个在假期里拼凑出来的东西来说已经很令人印象深刻；但也有人提醒，玩具型或专用调度器往往会遗漏边缘情况，在其他场景下可能不如更通用的调度器。
- 关于内核编译通常是 CPU 绑定还是 IO/内存绑定，也存在争论；共识是“这取决于系统”。
交互性与“活动窗口”优先级
- 多位评论者强调，负载下桌面的响应性才是有意思的指标。
- 有些人惊讶于 Linux 没有更激进地优先处理前台/交互式进程；另一些人则指出，内核并没有“活动窗口”的固有概念，只能使用启发式方法。
- 还提到了过去以及内核外、以交互性为目标的调度器，作为先例。
炒作、语言战争与社区动态
- 多人批评标题和第三方报道对一个业余实验进行了过度炒作，并助长了“用 Rust 重写一切”的文化。
- 也有人反驳说，实验是健康的，Rust 在内核中的使用值得报道，而且每个语言社区都会经历一段炒作期。
- 还有人担心，围绕“unsafe languages”的强硬倡导和道德化表述会让人反感。
安全性与故障模式
- 有人提出关于死锁以及如何确保用户空间调度器本身能获得 CPU 时间的问题。
- 回应中描述了一个看门狗：它会卸载行为异常的调度器并回退到默认调度器，同时还有逻辑确保在需要时调度器任务能够运行。
- 将调度卸载到用户空间被认为确实有开销和风险，因此其他调度器可能更适合生产环境。