LWN：小话题：Realtime, Futex, ntfs3！-优快云博客

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

Short subjects: Realtime, Futexes, and ntfs3

By Jonathan Corbet
August 16, 2021
DeepL assisted translation
https://lwn.net/Articles/866112/

即使在（北半球）夏天大家都因为炎炎夏日而非常慵懒的日子里，内核社区也仍然保持着繁忙。编者看到了许多方面的进展。但是因为各种原因无法为它们专门写出一系列专题文章。因此现在是时候该补上这些话题了。请继续阅读本文来了解 realtime patch set、重新塑造 futexes，以及对 ntfs3 文件系统的更新。

Realtime

realtime preemption （实时抢占）是一个历史悠久的话题。它第一次出现在 LWN 上是在 2004 年。多年来，这项工作对整个内核开发产生了重大影响。许多最近才加入 core kernel 的一些功能，其实都起源于 realtime 代码库。不过，realtime 相关工作中最早的一部分，也就是可抢占的锁功能（preemptible locking infrastructure），仍然游离在 mainline 之外。如果不合入这些锁相关的改动的话，mainline 就不可能满足那些实时性高的场景所需要的响应时间要求。

这个特别的锁实现，将几乎所有的锁（包括 spinlock），都变成了睡眠锁（sleeping lock）。这就确保了更高优先级的任务总是能够迅速加进来占有处理器。这是一种让内核开发者感到非常担忧的改动，因为在这个位置如果有 bug 会导致各种莫名其妙的问题。因此，没人有胆子敢预测这个锁功能何时会被合并到 mainline。编者很清楚这一点，因为编者曾非常自信地预测它将在一年内被合入 mainline，那是在 2007 年的时候。

不过，人们倾向于认为最终的日子已经快要到来了。Realtime 的开发者 Thomas Gleixner 已经将这部分锁基础设施功能重新带回到了邮件列表，开始了 review。这是由 72 个 patch 组成的改动，其第五版已于 8 月 15 日发布。使用了正常 config 配置的内核在带上这些 patch 后的表现应该没有什么差异，但那些打开了 realtime 配置的内核则可以用上 realtime 专用的 mutex、wait/wound mutex、reader/writer semaphore 信号量、spinlock 以及 reader/writer lock。

回复这组 patch 的 comment 已经越来越少了，目前看起来并没有什么人反对。不过我们还是要注意，Linus Torvalds 尚未就这个问题发表他的看法。除非有什么意外，否则的话这部分核心的 realtime 代码最终会进入 mainline。然而，编者还是太有经验了，也很聪明、胆小，可不敢猜测这件事的具体时间。

A smaller step for futex2

关于 realtime 这个改动的 review 很少，也许是因为大多数开发者都害怕深入分析如此复杂的代码。然而，在内核中还有一些地方更让人害怕，比如 futex 子系统肯定是其中之一。Futexes 为用户空间提供了 fast mutex 功能。起初这只是一个很简单的子系统，但没能一直保持下去。随着时间的推移，很明显，人们越来越意识到 futexes 需要进行一些改进，从而能更适合当前的工作场景。同时，也抛弃 multiplexer futex() 这个系统调用。

近来 André Almeida 一直在推动他提出的 futex2 提案，希望对这方面进行改进。他的改动是将 futex 功能分成几个各自独立的系统调用，并支持 lock size，当然还有别的改动。虽然人们对这项工作很感兴趣，但进展却很缓慢（情况其实比缓慢更糟）。内核目前基本上比起一两年前的 futex 子系统基本上没有多大变化。

为了推动进展，Almeida 发布了一个新的 patch set，先大大地降低了自己的雄心。这组 patch 不再试图加入一个使用了一套完全不同的系统调用的子系统，而是增加了一个能与现有 futexes 一起配合工作的系统调用：

struct futex_waitv {
    uint64_t val;
    void *uaddr;
    unsigned int flags;
};

int futex_waitv(struct futex_waitv *waiters, unsigned int nr_futexes,
                unsigned int flags, struct timespec *timo);

这个函数将使得调用进程可以同时等待好几个 futex，当一个或多个 futexes 能够被获取到（或发生超时）时就返回。目前的 futex API 尚不支持这一功能，但事实证明它对游戏引擎这种场景特别有用，在使用新的系统调用时性能明显得到了提高。相关的 documentation patch 里更详细地介绍了新的 API。

这个补丁集在发布后的一周内没有得到任何评论。如果我们假设这些沉默意味着没有反对意见（而不是人们没兴趣 review）的话，这项 futex2 的改动可能会在不久之后进入 mainline。futex2 的其他工作是否会在接下来继续跟进，这取决于推动这些功能的使用场景的说服力有多大。如果 futex_waitv() 已经解决了最糟糕的问题了的话，那可能就没有什么动力去推动其他的改动了。

Waiting for ntfs3

内核长期以来一直带 NTFS 文件系统的支持，但它的性能和功能方面一直都有些不足。用户社区很希望能拥有更好的实现。从各方面来看，Konstantin Komarov 发布的 ntfs3 实现确实就是人们所期望的 “更好的东西”，但是目前仍然不清楚它何时会被合并。这项工作是在一年前首次发布的，而第 27 版改动是在 7 月 29 日发布。

事实证明，这个功能迟迟未进入 mainline 使得用户感到很沮丧。Neal Gompa 的抱怨就很典型：

我知道和你们这些了不起的人相比，我只是一个低级用户而已，但是看到这个对很多人会有重大影响的功能在这几个月没有任何进展，这让人很沮丧。

这是一个耻辱，因为 ntfs3 驱动比目前的 ntfs 驱动要好得多，而且是对无人维护的 ntfs-3g FUSE 实现版本的一种可靠替代方案。

Torvalds 说，也许现在是时候合并这些代码了，但是，这可能并不会马上发生。

目前，ntfs3 面临的最大障碍似乎是对其背后的开发工作的担忧。从公开的信息来看，ntfs3 似乎是一个人进行开发的项目，这让其他的文件系统开发者感到有些紧张。因为这些开发者一直在报告 ntfs3 相关的 test 失败，但并没有得到解决。同时，Komarov 有时候对人们的提问没有回应。例如，在 4 月初发布的第 26 版上的各种 review 意见并没有得到答复。这种沉默，带给人的印象是 ntfs3 背后没有很多开发精力在支持它。（值得注意的是，其他一些开发者对 Komarov 的回复情况感到满意）

不足为奇，文件系统开发者对要承担一个新的 NTFS 实现并不多么热心，因为它可能会有严重的问题，而且没有人许诺提供可靠的支持。ntfs3 要想得到合并，就需要以某种方式来解决这些担忧。正如 Ted Ts'o 所建议的那样，一种方法是其他开发者（也许是一个或多个希望在内核中看到更好的 NTFS 实现的发行版提供商的开发者），能开始为 ntfs3 贡献补丁，并承诺帮助作者继续维护。

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

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

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