LWN：采用latency nice改善响应时间！

关注了就能看到更多这么棒的文章哦～

Improved response times with latency nice

By Jonathan Corbet
March 17, 2022
DeepL assisted translation
https://lwn.net/Articles/887842/

CPU 调度是一项非常具有挑战性的任务，scheduler （调度器）必须确保每个进程都能公平地获取到 CPU 时间，同时也要尊重 CPU affinity 的配置从而避免进程被迫放弃 cache 中已有的可以快速访问的内容，并使系统中的所有 CPU 都保持繁忙。即使如此，如果特定的进程不能迅速得到它们的 CPU 份额，用户也会变得很不满意。例如，多年来关于桌面环境的相应速度（desktop responsiveness）的争论就是由此产生的。最近由 Vincent Guittot 提出的 "latency-nice priority proposal" 的提议就是希望能提供一个新的工具来帮助那些对延迟很敏感的应用程序能更快地获得 CPU 来使用。

多年来，有许多方法被用来改善重要进程的响应时间。例如，传统的 Unix "nice"值就可以用来提高一个进程的优先级。这确实有起作用，但一个进程的 nice 值并不能直接对应到 latency 上，是用来控制该进程可以消耗多少 CPU 时间的，但不能控制该进程什么时候可以开始运行。使用 realtime 优先级就可以让调度器来快速运行某个进程，特别是在启用了 realtime preemption （实时抢占）的情况下，但是其他用 realtime 优先级运行的进程也可以接管系统。

latency-nice 概念是一种试图解决这些问题的新方法，它适用于大多数进程在使用的 completely fair 调度器，所以不需要设置 realtime 优先级了。它新增了一个 nice 值，跟当前现存的 nice 值类似，是一个在-20 和 19 之间的数字。数字越小，优先级就越高，所以最高优先级的 latency-nice 值是 -20。与传统的 nice 值相同，任何进程都可以增加它的 latency-nice 配置，但要想降低的话就需要 CAP_SYS_NICE 这个 capability 了。

传统的 nice 值是通过调节一个进程相对于系统中其他进程可以消耗多少 CPU 时间来实现的，nice 值较低的进程可以获得更多的 CPU 时间。相反，改变 latency-nice 值并不改变一个进程可能消耗的 CPU 时间数量。然而，它确实会对该时间的可用时间产生影响。具有较低 latency-nice 值的进程被认为是对延迟更敏感的，因此不应该在获取到 CPU 之前等待太久。

采用这个模型之后，latency nice 的实现就相对简单了。每当有一个被阻塞的进程被唤醒时，调度器必须决定是立即运行它，还是把它放到运行队列中，让它等待 CPU。现在有很多因素会影响到这个决定，而 latency-nice 机制又增加了一个新的因素。如果新的进程比正在 CPU 中运行的进程有更高的 latency-nice 优先级，并且新的进程在其当前时间片中还有可用的 CPU 时间，那么新的进程就可以抢占当前正在运行的进程。新进程不会比以前能得到更多的 CPU 时间，但它有权在当前时间片未用完时可以更快地占有 CPU。

同样，一个具有较高 latency-nice 值的进程（因此，优先级较低）将不会抢占其他正在运行的进程。因此，要等到优先级较高的进程用完了它们的当前时间片之后，这个进程才能开始使用分配给它的 CPU 时间。这个进程也将得到它有权得到的所有时间，但它不会阻塞其他进程，而且由于它也不会抢占其他进程，因此一般来说会减少上下文切换。

传统的 nice 值是通过 nice() 系统调用设置的。latency-nice 值则是由 sched_setattr() 控制的。一个新的字段（latency_nice）已经被添加到传递给该系统调用的 sched_attr 结构中，并且 SCHED_FLAG_LATENCY_NICE flag 是用来指示需要使用一个新的 latency-nice 值了。也可以使用 scheduler cgroup 来管理 latency-nice 值，为此专门提供了一个新的 sysfs 节点（名为 latency）。

该系列的一个 patch 中包括了一些基准测试结果，显示了 latency-nice 的工作原理。在运行 hackbench 基准测试时，由于发生的抢占次数较少，所以在高 latency-nice 值的情况下产生了更好的性能。在 latency-nice 值较低的情况下运行 cyclictest，显示出测试中测得的 latency 值就大大降低了。总的来说，这套 patch 的效果正如预期一样。

此前，这项工作是由 Parth Shah 开发的；该 patch set 的第五次修订是在 2020 年 2 月发布的。到那时，这项工作已经获得了一些 Reviewed-by tag，但此后就停滞了。有趣的是，它已经具备了用来管理 latency-nice 值的那些基础设施，但实际上并没有在 scheduler 中实现任何新的行为。当时，有一些关于系统应该如何响应 latency-nice 值的讨论，并且在 OSPM 2020 会议上进行了关于 latency-nice 值的讨论，但似乎没有达成共识什么样的行为才是正确的。

两年后，Guittot 将这一工作拣起来，并增加了上述的唤醒方面的实现。截至本文写作时，对这项工作的 review 很少。不过，改善重要进程的响应时间一直以来都是许多开发者非常希望具备的功能之一。如果进一步的测试表明 latency-nice 机制代表了正确方向，那么这次的推动很可能将会让这项工作能成功进入 mainline kernel。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～