Linux 在 Steam 的占比刚突破 5%，但真正值得关注的不是数字本身，而是性能改善的来源正在发生位移——从 Wine/Proton 的用户态模拟，下沉到 Linux 内核的原生实现。NTSYNC 是这一趋势的最新例证：它把 Windows NT 的同步机制直接写进内核，让那些重度依赖 mutex、semaphore 的 Windows 游戏在 Linux 上少走一大段弯路。
同步原语：游戏帧率的地基
Windows 游戏大量使用 NT 内核的同步对象——mutex、semaphore、event、waitable timer。多线程渲染、资源加载、帧同步，几乎每一帧的渲染管线都要经过这些原语协调。在 Linux 上运行 Windows 游戏时，这些调用必须被翻译。
过去，翻译发生在 Wine/Proton 的用户态。Wine 维护了一套 NT 同步对象的用户态模拟：每个 mutex 是一个 pthread mutex，每个 semaphore 是一个 POSIX semaphore，每次 NtWaitForMultipleObjects 被拆解成多步 POSIX 调用。问题在于：
- 跨进程同步必须走内核。用户态的 pthread mutex 只能在同一进程内有效，跨进程的 NT mutex 需要回退到文件锁或共享内存方案，开销陡增。
NtWaitForMultipleObjects无法一对一映射。Windows 可以同时等待最多 64 个对象，POSIX 没有等价接口，Wine 只能逐个轮询或用复杂的多线程桥接，延迟和 CPU 开销双双上升。- 死锁检测和优先级继承缺失。NT 内核有内置的优先级继承防止优先级反转，用户态模拟很难完整复刻。
这些差距在轻量游戏里不明显，但在 CPU 密集、线程数多的 3A 大作中，同步开销直接吃掉帧率。
NTSYNC：把 NT 同原语搬进内核
NTSYNC 由 Wine 开发者 Elizabeth Figura 提出，已在 6.14 版本区间进入 Linux 内核主线（具体合并窗口随版本推进）。它的核心思路很简单：在内核里直接提供 NT 语义的同步对象，Wine 不再模拟，而是直接使用。
NTSYNC 注册了一个字符设备 /dev/ntsync，Wine 通过 ioctl 创建和管理同步对象：
| NT 对象 | NTSYNC ioctl 创建命令 | 内核实现 |
|---|---|---|
| Mutex | NTSYNC_IOC_CREATE_MUTEX |
内核 mutex + 优先级继承 |
| Semaphore | NTSYNC_IOC_CREATE_SEM |
内核 semaphore |
| Event | NTSYNC_IOC_CREATE_EVENT |
内核 event（自动/手动复位） |
| Timer | NTSYNC_IOC_CREATE_TIMER |
高精度内核定时器 |
关键突破在等待机制。NTSYNC 提供了 NTSYNC_IOC_WAIT_ALL 和 NTSYNC_IOC_WAIT_ANY 两个 ioctl，分别对应 Windows 的 WaitForMultipleObjects 的 "等待全部" 和 "等待任一" 模式。内核一次性完成多对象等待，不再需要用户态拆解轮询。
这意味着一个 NtWaitForMultipleObjects(handleArray, 64, WAIT_ALL, timeout) 调用，从用户态 64 次轮询变成一次 ioctl 进入内核、一次唤醒返回。路径缩短的幅度，在高频同步场景下非常可观。
性能差距：实测数据说话
Elizabeth Figura 在邮件列表中提交了基准测试。核心结果：
- 单对象等待：NTSYNC 比 Wine 用户态模拟快约 20-30%。差距来自 ioctl 直接进入内核 vs 用户态锁 + futex 回退的路径长度。
- 多对象等待（WAIT_ALL，8 个对象）：NTSYNC 快 4-5 倍。Wine 需要逐个获取锁再检查一致性，NTSYNC 在内核里原子完成。
- 跨进程 mutex：NTSYNC 快 3-4 倍。用户态跨进程必须走共享内存 + futex，NTSYNC 的内核 mutex 天然跨进程。
对玩家而言，这些数字翻译成帧率提升：在《赛博朋克 2077》这类多线程重度同步的游戏中，帧时间方差缩小，最低帧提升明显——平均帧可能只多了 5-8%，但卡顿次数和 1% low 帧的改善远大于此。
实操：检查和启用 NTSYNC
NTSYNC 目前仍在逐步进入主线，不同发行版的状态不同。以下命令帮你确认当前内核是否支持，并在支持时启用它。
# 1. 检查内核版本（6.14+ 开始逐步合并 NTSYNC）
uname -r
# 2. 检查 NTSYNC 模块是否已编译进内核
grep -i ntsync /lib/modules/$(uname -r)/modules.builtin
# 或检查是否作为可加载模块
find /lib/modules/$(uname -r) -name '*ntsync*'
# 3. 如果是可加载模块，手动加载
sudo modprobe ntsync
# 4. 确认设备节点存在
ls -la /dev/ntsync
# 预期输出类似：crw-rw-rw- 1 root root 10, 200 /dev/ntsync
# 5. 检查当前 Wine/Proton 是否已启用 NTSYNC
# Proton 9+ 和 Wine 9.20+ 会自动检测 /dev/ntsync
# 可通过环境变量强制启用（调试用）
export WINE_ntsync=1
# 6. 快速验证：运行一个 Windows 同步密集程序并观察
# 用 Proton 运行 Steam 游戏，同时监控帧时间
steam -protonlog %command%
# 在日志中搜索 "ntsync" 确认是否走内核路径
如果你想自己写一个最小测试来对比 NTSYNC 和传统 futex 的等待延迟，可以用以下 C 程序（需要内核 6.14+ 且 /dev/ntsync 可用）：
// ntsync_minimal_test.c — 最小化 NTSYNC 等待延迟对比
// 编译: gcc -O2 -o ntsync_test ntsync_minimal_test.c
// 运行: ./ntsync_test
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <time.h>
#include <sys/ioctl.h>
#include <linux/ntsync.h> // 需要内核头文件 6.14+
#define ITERATIONS 100000
static double now_sec(void) {
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
return ts.tv_sec + ts.tv_nsec * 1e-9;
}
int main(void) {
int fd = open("/dev/ntsync", O_RDWR);
if (fd < 0) {
perror("open /dev/ntsync — 你的内核可能尚未支持 NTSYNC");
return 1;
}
// 创建一个 semaphore，初始值 1
struct ntsync_sem_args sem_args = {0};
sem_args.count = 1;
sem_args.max = 1;
if (ioctl(fd, NTSYNC_IOC_CREATE_SEM, &sem_args) < 0) {
perror("CREATE_SEM");
close(fd);
return 1;
}
double start = now_sec();
for (int i = 0; i < ITERATIONS; i++) {
// wait: 获取 semaphore (count 从 1 变 0)
struct ntsync_wait_args wait = {0};
wait.timeout = ~0ULL; // 无限等待
wait.objs = (uintptr_t)&sem_args.sem;
wait.count = 1;
wait.owner = 0;
ioctl(fd, NTSYNC_IOC_WAIT_ANY, &wait);
// release: 释放 semaphore (count 从 0 变 1)
sem_args.count = 0; // 当前值
ioctl(fd, NTSYNC_IOC_SEM_POST, &sem_args);
}
double elapsed = now_sec() - start;
printf("NTSYNC: %d 次 wait+post 耗时 %.3f ms\n"
"单次往返: %.1f ns\n",
ITERATIONS, elapsed * 1000,
elapsed / ITERATIONS * 1e9);
close(sem_args.sem); // 关闭 semaphore 对象
close(fd);
return 0;
}
注意：
<linux/ntsync.h>头文件随内核版本更新，ioctl 命令号和结构体字段可能调整。如果编译失败，先检查/usr/include/linux/ntsync.h是否存在，或从内核源码tools/testing/selftests/ntsync/目录拷贝头文件。
还在路上：边界与预期
NTSYNC 不是终点，而是方向标。几个值得留意的边界：
- 对象生命周期管理仍在完善。NT 同步对象有复杂的引用计数和命名空间规则（全局命名对象、进程私有对象），NTSYNC 目前覆盖了最常用的场景，但边缘情况（如
NtOpenSemaphore跨进程按名打开）仍在迭代。 - 64 对象等待上限尚未完全实现。Windows
WaitForMultipleObjects最多等 64 个对象，NTSYNC 当前实现有实际限制，极端场景可能仍需回退。 - 安全上下文和 ACL 暂不完整。NT 对象有安全描述符，NTSYNC 目前不做完整 ACL 检查——对游戏场景足够，但服务器场景需要更多工作。
- Wine/Proton 的适配是渐进的。Proton 9.x 已开始自动检测
/dev/ntsync，但并非所有同步路径都已切换。部分旧游戏仍走用户态回退。
对普通玩家而言，现在最实际的做法是：保持内核和 Proton 版本更新，不做额外配置。NTSYNC 的设计是零配置——设备存在就自动使用，不存在就静默回退。手动设置 WINE_ntsync=1 仅在调试或确认行为时需要。
对开发者和发行版维护者，关注点不同：
- 内核配置：确认
CONFIG_NTSYNC=y或模块已加载，/dev/ntsync权限为0666（Wine 以普通用户运行）。 - Proton 版本：Proton 9+ 才有 NTSYNC 支持，Steam 的 Proton Experimental 分支通常最先跟进。
- 回退测试：在启用 NTSYNC 后跑一遍目标游戏的基准帧率，对比禁用时的 1% low 帧——改善主要在这里。
NTSYNC 的意义超出它本身。它证明了一个趋势：Linux 游戏体验的瓶颈正在从"翻译层够不够完整"转向"内核够不够原生"。后续大概率还有更多 NT 语义入核——IO 完成、注册表、甚至部分窗口管理器的协同。当翻译层越来越薄，"Linux 上跑 Windows 游戏"就不再是模拟，而是同构。