Rust AMD CPU FSRM 指令内存对齐性能问题技术分析

博主： admin
发布时间：2026 年 01 月 27 日
18 次浏览
暂无评论
7399字数
分类： rust 技术新闻性能分析

# Rust AMD CPU FSRM 指令内存对齐性能问题技术分析

# 一、事件概述

## 1. 事件背景
Apache OpenDAL 项目开发者在性能测试中发现一个反常现象：使用 Rust 标准库读取文件比 Python 慢约 2 倍。这个发现引发了对底层内存拷贝机制的深入调查。

## 2. 问题现象
基准测试结果显示：
- Python 读取 64MB 文件：约 28.8ms
- Rust 使用 std fs 读取：约 28.0ms
- 但 Rust 的系统调用时间显著更高

## 3. 影响范围
- 影响 AMD Zen 架构处理器（Ryzen 9 5900HX、7800X3D 等）
- 特定条件：内存地址页对齐时触发
- 涉及 FSRM（Fast Short REP MOVS）CPU 特性

# 二、问题分析

## 1. 初始发现

作者 Xuanwo 在测试 OpenDAL Python 绑定时发现性能问题：

**测试代码（Python）：**
```python
import pathlib

root = pathlib.Path(__file__).parent
filename = "file"

def read_file_with_normal() -> bytes:
    with open(root / filename, "rb") as fp:
        result = fp.read()
    return result
```

**测试代码（Rust）：**
```rust
use std::io::Read;
use std::fs::OpenOptions;

fn main() {
    let mut bs = vec![0; 64 * 1024 * 1024];
    let mut f = OpenOptions::new()
        .read(true)
        .open("/tmp/test/file")
        .unwrap();
    f.read_exact(&mut bs).unwrap();
}
```

**基准测试结果：**
```
Benchmark 1: python test_fs.py
  Time (mean ± σ): 28.8 ms ± 1.9 ms
  [User: 12.8 ms, System: 15.8 ms]

Benchmark 2: ./opendal-test/target/release/opendal-test
  Time (mean ± σ): 28.0 ms ± 1.3 ms
  [User: 0.3 ms, System: 27.7 ms]
```

关键观察：Rust 版本在系统调用上花费了更多时间。

## 2. 深入调查

### A. 内存分配器差异

通过 perf 分析发现，Python 和 Rust 在内存分配行为上存在显著差异：

**Python 内存分配：**
- 使用大页分配（huge page）
- 避免了页对齐问题

**Rust 默认分配器：**
- 使用标准分配策略
- 容易产生页对齐的内存地址

### B. FSRM 指令问题

社区成员 lhecker 揭示了根本原因：

AMD CPU 的 FSRM（Fast Short REP MOVS）微码存在缺陷。该指令在处理内存拷贝时，由于无法获取物理内存地址，只能通过虚拟地址的低 12 位（页内偏移）来判断是否存在内存重叠。

检测逻辑为：
```
(source - destination) mod 4096 < vector_size
```

当源地址和目标地址页对齐（offset 为 0 或接近 0）时，FSRM 会误判存在重叠，退化为逐字节拷贝的慢速路径。

```mermaid
graph LR
    subgraph "正常情况 offset=0x10"
        A1[源地址] -->|不对齐| B1[目标地址]
        B1 --> C1[快速路径]
        C1 --> D1[性能: ~12ms]
    end
    subgraph "异常情况 offset=0"
        A2[源地址] -->|页对齐| B2[目标地址]
        B2 --> E1[FSRM 检测]
        E1 -->|误判重叠| E2[慢速路径]
        E2 --> D2[性能: ~30ms]
    end

style E2 fill:#f99
    style C1 fill:#9f9
```

![mermaid](https://static.op123.ren/static/54/548519163907b9d4.svg)

### C. C 语言复现

社区成员用纯 C 代码复现了问题：

```c
#include <stdio.h>
#include <stdlib.h>

#define FILE_SIZE 64 * 1024 * 1024 // 64 MiB

int main() {
    FILE *file;
    char *buffer;
    size_t result;

file = fopen("/tmp/file", "rb");
    if (file == NULL) {
        fputs("Error opening file", stderr);
        return 1;
    }

buffer = (char *)malloc(sizeof(char) * FILE_SIZE);
    if (buffer == NULL) {
        fputs("Memory error", stderr);
        fclose(file);
        return 2;
    }

// 关键：使用 offset 绕过 FSRM 问题
    result = fread(buffer+0x10, 1, FILE_SIZE, file);

if (result != FILE_SIZE) {
        fputs("Reading error", stderr);
        fclose(file);
        free(buffer);
        return 3;
    }

fclose(file);
    free(buffer);
    return 0;
}
```

**性能对比：**
```
Benchmark 1: python test_py.py
  Time (mean ± σ): 29.5 ms ± 0.8 ms

Benchmark 2: ./test_c (无 offset)
  Time (mean ± σ): 29.9 ms ± 0.6 ms

Benchmark 3: ./test_c (offset=0x10)
  Time (mean ± σ): 11.6 ms ± 0.4 ms
```

添加 0x10 字节偏移后，性能提升约 2.5 倍。

## 3. 性能分析数据

### perf stat 对比（AMD Ryzen 9 5900HX）

**有 offset（快速路径）：**
```
Performance counter stats for './a.out' (20 runs):
  15.39 msec task-clock
  41,239,117 cycles
  37,009,429 instructions
  13,965,813 L1-dcache-loads
  3,623,350 L1-dcache-load-misses (25.94%)
  590,613 L1-dcache-prefetches
  16,046 dTLB-loads
  14,040 dTLB-load-misses (87.50%)
```

**无 offset（慢速路径）：**
```
Performance counter stats for './a.out' (20 runs):
  30.89 msec task-clock
  90,321,344 cycles
  43,349,705 instructions
  127,845,213 L1-dcache-loads
  3,172,628 L1-dcache-load-misses (2.48%)
  1,843,493 L1-dcache-prefetches
  15,615 dTLB-loads
  12,825 dTLB-load-misses (82.13%)
```

关键差异：
- L1-dcache-loads：慢速路径是快速路径的 9 倍
- L1-dcache-prefetches：快速路径有预取，慢速路径几乎没有

### 热点汇编代码

perf record 显示热点在 `_copy_to_iter` 函数：

```asm
copy_user_generic():
  2.19  mov %rdx,%rcx
  2.19  mov %r12,%rsi
  92.45 rep movsb %ds:(%rsi),%es:(%rdi)
  0.49  nop
```

`rep movsb` 指令占据了 92.45% 的执行时间。

# 三、解决方案

## 1. 临时方案

### A. 添加内存偏移

在读取时添加固定的字节偏移：

```rust
// 不推荐：破坏内存布局
let mut bs = vec![0u8; size + 0x10];
let ptr = bs.as_mut_ptr().add(0x10);
// 使用 ptr 进行读取
```

### B. 使用 jemalloc

Rust 使用 jemalloc 作为全局分配器：

```toml
[dependencies]
tikv-jemallocator = "0.5"
```

```rust
use tikv_jemallocator::Jemalloc;

#[global_allocator]
static GLOBAL: Jemalloc = Jemalloc;
```

**测试结果：**
```
Benchmark 1: python test_fs.py
  Time (mean ± σ): 176.6 ms ± 1.5 ms

Benchmark 2: Rust with jemalloc
  Time (mean ± σ): 161.1 ms ± 4.4 ms
```

使用 jemalloc 后性能略优于 Python，但仍未达到理想状态。

## 2. 系统级解决方案

### A. 更新 CPU 微码

AMD 已在后续微码更新中修复此问题。用户应：
- 检查 BIOS/UEFI 更新
- 安装最新的 CPU 微码

### B. glibc 补丁

相关 bug 报告：
- Ubuntu: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2030515
- glibc upstream: https://sourceware.org/bugzilla/show_bug.cgi?id=30994

glibc 已添加绕过此问题的补丁。

## 3. 长期方案

### A. Rust 标准库

Rust 社区需要考虑：
- 在分配器层面避免页对齐
- 或在 std::fs::read 等函数中添加偏移

### B. 应用层应对

对于受影响的应用，可以：
1. 使用自定义内存分配器
2. 在读取时添加缓冲区偏移
3. 使用 mmap 替代 read

# 四、架构分析

## 1. 内存分配与读取流程

```mermaid
graph TB
    subgraph "应用层"
        A[Python]
        B[Rust]
    end
    subgraph "语言运行时"
        C[Python 分配器]
        D[Rust 默认分配器]
        E[jemalloc]
    end
    subgraph "系统调用层"
        F[read syscall]
    end
    subgraph "内核层"
        G[copy_page_to_iter]
        H[_copy_to_iter]
        I[rep movsb 指令]
    end

A -->|malloc| C
    B -->|malloc| D
    B -->|可选| E
    C --> F
    D --> F
    E --> F
    F --> G
    G --> H
    H --> I

style D fill:#f99
    style I fill:#ff9
    style C fill:#9f9
```

![mermaid](https://static.op123.ren/static/8f/8f5b67b9dbcca99f.svg)

## 2. FSRM 检测逻辑

AMD FSRM 检测内存重叠的逻辑：

```
IF ((source_addr - dest_addr) MOD 4096) < vector_size THEN
    // 可能存在重叠，使用安全但慢的路径
    USE byte-wise copy
ELSE
    // 确定不重叠，使用快速路径
    USE vectorized copy
END IF
```

问题在于：当源地址和目标地址都在不同页但对齐到页边界时，即使实际不重叠，也会触发慢速路径。

# 五、各方反应

## 1. 社区讨论

该问题在多个平台引发讨论：
- GitHub issue 获得大量关注
- Hacker News 技术讨论
- Rust 用户论坛

## 2. 技术分析

社区成员贡献了多个角度的分析：
- lhecker：揭示 FSRM 微码缺陷
- ryncsn：使用 perf 进行深入性能分析
- Harry-Chen：分析 CPU 缓存行为
- Yangff：测试不同偏移值的影响

## 3. 官方响应

- glibc 已发布修复补丁
- AMD 发布微码更新
- 此问题被标记为"not planned"（无法在应用层修复）

# 六、经验总结

## 1. 性能分析技巧

本次调查使用的方法：
- hyperfine：基准测试
- perf：性能计数器分析
- perf record：热点分析
- eBPF：系统调用追踪

## 2. 调试启示

1. 不要预设结论
   - 初步判断是 Rust 问题，实际是 CPU 微码缺陷

2. 多语言对比验证
   - C 语言复现证明了问题与 Rust 无关

3. 关注系统层细节
   - 内存对齐、CPU 指令等底层因素影响巨大

## 3. 最佳实践建议

### A. 性能关键代码
- 避免依赖页对齐的内存分配
- 考虑使用 jemalloc 等高性能分配器
- 添加适当的内存偏移

### B. 可移植性考虑
- 检测 CPU 特性
- 提供多路径实现
- 针对不同硬件优化

### C. 测试策略
- 在多种 CPU 架构上测试
- 使用真实的性能场景
- 关注系统调用级别的指标

# 七、相关资源

## 1. 原始讨论
- GitHub Issue: https://github.com/apache/opendal/issues/3665
- 作者博客: https://xuanwo.io/2023/04-rust-std-fs-slower-than-python/

## 2. 技术文档
- AMD FSRM: https://en.wikipedia.org/wiki/CPUID#EAX.3D1:_Processor_Info_and_Feature_Bits
- glibc Bug 30994: https://sourceware.org/bugzilla/show_bug.cgi?id=30994

## 3. 相关问题
- Rust 用户论坛讨论: https://users.rust-lang.org/t/std-read-slow/85424/15

***

## 参考资料

1. [Apache OpenDAL Issue #3665](https://github.com/apache/opendal/issues/3665)
2. [Xuanwo 的技术博客分析](https://xuanwo.io/2023/04-rust-std-fs-slower-than-python/)
3. [glibc Bug Report - Bug 30994](https://sourceware.org/bugzilla/show_bug.cgi?id=30994)
4. [Ubuntu Bug Report - Bug 2030515](https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2030515)

最后修改：2026 年 01 月 27 日

如果觉得我的文章对你有用，请随意赞赏

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

评论 *

私密评论

名称 *

🎲

邮箱 *

地址

Rust AMD CPU FSRM 指令内存对齐性能问题技术分析

admin • 2026 年 01 月 27 日

# Rust AMD CPU FSRM 指令内存对齐性能问题技术分析

# 一、事件概述

## 2. 问题现象
基准测试结果显示：
- Python 读取 64MB 文件：约 28.8ms
- Rust 使用 std fs 读取：约 28.0ms
- 但 Rust 的系统调用时间显著更高

## 3. 影响范围
- 影响 AMD Zen 架构处理器（Ryzen 9 5900HX、7800X3D 等）
- 特定条件：内存地址页对齐时触发
- 涉及 FSRM（Fast Short REP MOVS）CPU 特性

# 二、问题分析

## 1. 初始发现

作者 Xuanwo 在测试 OpenDAL Python 绑定时发现性能问题：

**测试代码（Python）：**
```python
import pathlib

root = pathlib.Path(__file__).parent
filename = "file"

def read_file_with_normal() -> bytes:
    with open(root / filename, "rb") as fp:
        result = fp.read()
    return result
```

**测试代码（Rust）：**
```rust
use std::io::Read;
use std::fs::OpenOptions;

**基准测试结果：**
```
Benchmark 1: python test_fs.py
  Time (mean ± σ): 28.8 ms ± 1.9 ms
  [User: 12.8 ms, System: 15.8 ms]

Benchmark 2: ./opendal-test/target/release/opendal-test
  Time (mean ± σ): 28.0 ms ± 1.3 ms
  [User: 0.3 ms, System: 27.7 ms]
```

关键观察：Rust 版本在系统调用上花费了更多时间。

## 2. 深入调查

### A. 内存分配器差异

通过 perf 分析发现，Python 和 Rust 在内存分配行为上存在显著差异：

**Python 内存分配：**
- 使用大页分配（huge page）
- 避免了页对齐问题

**Rust 默认分配器：**
- 使用标准分配策略
- 容易产生页对齐的内存地址

### B. FSRM 指令问题

社区成员 lhecker 揭示了根本原因：

检测逻辑为：
```
(source - destination) mod 4096 < vector_size
```

当源地址和目标地址页对齐（offset 为 0 或接近 0）时，FSRM 会误判存在重叠，退化为逐字节拷贝的慢速路径。

style E2 fill:#f99
    style C1 fill:#9f9
```

![mermaid](https://static.op123.ren/static/54/548519163907b9d4.svg)

### C. C 语言复现

社区成员用纯 C 代码复现了问题：

```c
#include <stdio.h>
#include <stdlib.h>

#define FILE_SIZE 64 * 1024 * 1024 // 64 MiB

int main() {
    FILE *file;
    char *buffer;
    size_t result;

file = fopen("/tmp/file", "rb");
    if (file == NULL) {
        fputs("Error opening file", stderr);
        return 1;
    }

buffer = (char *)malloc(sizeof(char) * FILE_SIZE);
    if (buffer == NULL) {
        fputs("Memory error", stderr);
        fclose(file);
        return 2;
    }

// 关键：使用 offset 绕过 FSRM 问题
    result = fread(buffer+0x10, 1, FILE_SIZE, file);

if (result != FILE_SIZE) {
        fputs("Reading error", stderr);
        fclose(file);
        free(buffer);
        return 3;
    }

fclose(file);
    free(buffer);
    return 0;
}
```

**性能对比：**
```
Benchmark 1: python test_py.py
  Time (mean ± σ): 29.5 ms ± 0.8 ms

Benchmark 2: ./test_c (无 offset)
  Time (mean ± σ): 29.9 ms ± 0.6 ms

Benchmark 3: ./test_c (offset=0x10)
  Time (mean ± σ): 11.6 ms ± 0.4 ms
```

添加 0x10 字节偏移后，性能提升约 2.5 倍。

## 3. 性能分析数据

### perf stat 对比（AMD Ryzen 9 5900HX）

关键差异：
- L1-dcache-loads：慢速路径是快速路径的 9 倍
- L1-dcache-prefetches：快速路径有预取，慢速路径几乎没有

### 热点汇编代码

perf record 显示热点在 `_copy_to_iter` 函数：

```asm
copy_user_generic():
  2.19  mov %rdx,%rcx
  2.19  mov %r12,%rsi
  92.45 rep movsb %ds:(%rsi),%es:(%rdi)
  0.49  nop
```

`rep movsb` 指令占据了 92.45% 的执行时间。

# 三、解决方案

## 1. 临时方案

### A. 添加内存偏移

在读取时添加固定的字节偏移：

```rust
// 不推荐：破坏内存布局
let mut bs = vec![0u8; size + 0x10];
let ptr = bs.as_mut_ptr().add(0x10);
// 使用 ptr 进行读取
```

### B. 使用 jemalloc

Rust 使用 jemalloc 作为全局分配器：

```toml
[dependencies]
tikv-jemallocator = "0.5"
```

```rust
use tikv_jemallocator::Jemalloc;

#[global_allocator]
static GLOBAL: Jemalloc = Jemalloc;
```

**测试结果：**
```
Benchmark 1: python test_fs.py
  Time (mean ± σ): 176.6 ms ± 1.5 ms

Benchmark 2: Rust with jemalloc
  Time (mean ± σ): 161.1 ms ± 4.4 ms
```

使用 jemalloc 后性能略优于 Python，但仍未达到理想状态。

## 2. 系统级解决方案

### A. 更新 CPU 微码

AMD 已在后续微码更新中修复此问题。用户应：
- 检查 BIOS/UEFI 更新
- 安装最新的 CPU 微码

### B. glibc 补丁

相关 bug 报告：
- Ubuntu: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2030515
- glibc upstream: https://sourceware.org/bugzilla/show_bug.cgi?id=30994

glibc 已添加绕过此问题的补丁。

## 3. 长期方案

### A. Rust 标准库

Rust 社区需要考虑：
- 在分配器层面避免页对齐
- 或在 std::fs::read 等函数中添加偏移

### B. 应用层应对

对于受影响的应用，可以：
1. 使用自定义内存分配器
2. 在读取时添加缓冲区偏移
3. 使用 mmap 替代 read

# 四、架构分析

## 1. 内存分配与读取流程

A -->|malloc| C
    B -->|malloc| D
    B -->|可选| E
    C --> F
    D --> F
    E --> F
    F --> G
    G --> H
    H --> I

style D fill:#f99
    style I fill:#ff9
    style C fill:#9f9
```

![mermaid](https://static.op123.ren/static/8f/8f5b67b9dbcca99f.svg)

## 2. FSRM 检测逻辑

AMD FSRM 检测内存重叠的逻辑：

问题在于：当源地址和目标地址都在不同页但对齐到页边界时，即使实际不重叠，也会触发慢速路径。

# 五、各方反应

## 1. 社区讨论

该问题在多个平台引发讨论：
- GitHub issue 获得大量关注
- Hacker News 技术讨论
- Rust 用户论坛

## 2. 技术分析

## 3. 官方响应

- glibc 已发布修复补丁
- AMD 发布微码更新
- 此问题被标记为"not planned"（无法在应用层修复）

# 六、经验总结

## 1. 性能分析技巧

本次调查使用的方法：
- hyperfine：基准测试
- perf：性能计数器分析
- perf record：热点分析
- eBPF：系统调用追踪

## 2. 调试启示

1. 不要预设结论
   - 初步判断是 Rust 问题，实际是 CPU 微码缺陷

2. 多语言对比验证
   - C 语言复现证明了问题与 Rust 无关

3. 关注系统层细节
   - 内存对齐、CPU 指令等底层因素影响巨大

## 3. 最佳实践建议

### A. 性能关键代码
- 避免依赖页对齐的内存分配
- 考虑使用 jemalloc 等高性能分配器
- 添加适当的内存偏移

### B. 可移植性考虑
- 检测 CPU 特性
- 提供多路径实现
- 针对不同硬件优化

### C. 测试策略
- 在多种 CPU 架构上测试
- 使用真实的性能场景
- 关注系统调用级别的指标

# 七、相关资源

## 1. 原始讨论
- GitHub Issue: https://github.com/apache/opendal/issues/3665
- 作者博客: https://xuanwo.io/2023/04-rust-std-fs-slower-than-python/

## 2. 技术文档
- AMD FSRM: https://en.wikipedia.org/wiki/CPUID#EAX.3D1:_Processor_Info_and_Feature_Bits
- glibc Bug 30994: https://sourceware.org/bugzilla/show_bug.cgi?id=30994

## 3. 相关问题
- Rust 用户论坛讨论: https://users.rust-lang.org/t/std-read-slow/85424/15

***

## 参考资料

Rust AMD CPU FSRM 指令内存对齐性能问题技术分析

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

搭建国内LabHub

CentOS 7.9 编译并使用rpm方式升级openssh9.6p1（包括后续更新9.8p1等）

一天从 redis 大 key 开始

安装eve-ng

重装ensp

灵长类厌恶条件下动机调节的纹状体苍白球通路机制技术分析

一次证书问题引发的一系列DNS悬疑问题排查

hf-mem：Hugging Face 模型推理内存估算 CLI 工具

深入架构原理与实践

LKY Office Tools - 便利安装office

Rust AMD CPU FSRM 指令内存对齐性能问题技术分析

发表评论 取消回复 使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

Rust AMD CPU FSRM 指令内存对齐性能问题技术分析

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款