Node.js在ARM与x86架构下epoll调用差异的技术问询

执行以下代码：

strace node -e 'setTimeout(()=>{console.log("hola")},10000)'

在**ARM架构实例（Graviton c7g.2xlarge，Ubuntu 20.04.3 LTS）**上使用 Node.js v18.12.1 时，strace 显示调用 epoll_pwait：

user@laptop:~$ strace -e epoll_pwait,epoll_wait -c node -e 'setTimeout(()=>{console.log("hola")},10000)' 
hola
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
  0.00    0.000000           0        10           epoll_pwait
------ ----------- ----------- --------- --------- ----------------
100.00    0.000000                    10           total

而在**AMD x86架构实例（c6a.2xlarge，Ubuntu 20.04.5 LTS）**上同版本 Node.js，strace 显示调用 epoll_wait：

user@laptop:~$ strace -e epoll_pwait,epoll_wait -c node -e 'setTimeout(()=>{console.log("hola")},10000)' 
hola
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.000012           1        10           epoll_wait
------ ----------- ----------- --------- --------- ----------------
100.00    0.000012                    10           total

技术疑问 #

1. 为何Node.js在ARM架构下使用epoll_pwait，在x86架构下使用epoll_wait？
2. 使用epoll_pwait与epoll_wait是否存在性能差异？
3. 是否可通过配置统一该行为，或我的分析存在遗漏？

解答 #

1. 架构差异导致的调用选择 #

Node.js 的事件循环底层依赖 libuv 库处理IO多路复用。libuv 会根据目标架构和系统内核特性自动选择最优的系统调用：

• epoll_pwait 是 epoll_wait 的扩展，支持在调用时原子性地设置信号掩码，避免信号处理相关的竞态条件。
• ARM架构的Linux内核（尤其是AWS Graviton所用的内核版本）对epoll_pwait的支持和优化更完善，且libuv在ARM平台的编译配置中默认优先选择epoll_pwait；而x86平台的libuv配置则保留了对epoll_wait的默认使用，这可能是因为x86平台上传统的epoll_wait兼容性更广泛，或者内核层面的差异导致的选择倾向。

2. 性能差异分析 #

两者的性能差异极小，几乎可以忽略：

• epoll_pwait 比 epoll_wait 多了信号掩码的原子操作，但这个操作的开销非常低，在常规IO场景下不会带来明显性能变化。
• 只有在频繁处理信号的场景中，epoll_pwait 因为避免了额外的信号掩码切换系统调用，才会体现出微弱的优势；反之，epoll_wait 在无信号处理的场景下，开销和epoll_pwait基本一致。
• 从你提供的strace结果来看，两者的调用次数相同，耗时差异也在系统调用的误差范围内，实际业务场景中不会有可感知的区别。

3. 统一行为的可能性及分析遗漏点 #

• 配置统一行为：可以通过修改libuv的编译选项强制指定使用epoll_wait或epoll_pwait，但需要重新编译Node.js。具体来说，在编译libuv时可以定义UV_USE_EPOLL_WAIT或UV_USE_EPOLL_PWAIT宏来覆盖默认选择。不过这种操作没有必要，因为两者的行为和性能差异极小，且libuv的默认选择已经适配了对应平台的最优特性。
• 分析遗漏点：需要确认两个实例的Linux内核版本是否一致——Ubuntu 20.04.3和20.04.5的内核版本可能存在差异，这也会影响libuv对系统调用的选择。另外，Node.js的预编译包在不同架构下的libuv配置可能不同，如果你是使用官方预编译包，这种差异是官方根据平台特性优化后的结果。

内容的提问来源于stack exchange，提问作者palash kulshreshtha