arm64 上 memcopy 内核是如何实现高性能的

</div>

📋 问题定位

• 内核子系统: ARM64 架构核心库 (arch/arm64/lib/)
• 关键函数: memcpy() → __pi_memcpy() (PIE 重定向别名)
• 核心文件: arch/arm64/lib/memcpy.S, arch/arm64/lib/copy_template.S

🎯 原理说明：ARM64 内核 memcpy 的高性能实现

1. 整体架构

ARM64 内核的 memcpy 是一个纯汇编实现，位于 arch/arm64/lib/memcpy.S。它使用了一个关键的模板文件 copy_template.S，该模板被 memcpy 和 copy_from_user / copy_to_user 共用，确保内核中所有内存拷贝路径都获得一致的优化。

其入口定义经过特殊处理：

/* arch/arm64/lib/memcpy.S */
1. memcpy 被重命名为 __pi_memcpy（位置无关代码）
2. 通过 SYM_FUNC_START_ALIAS(__memcpy) 和 SYM_FUNC_ALIAS(memcpy, __pi_memcpy) 建立别名链
3. 最终 memcpy() → __memcpy() → __pi_memcpy()

2. 核心优化技术

ARM64 内核 memcpy 的高性能来自以下六大优化策略：

3. 汇编级实现细节（核心主循环伪代码）

/*
 * 主循环的核心思路：
 * 寄存器分配: 使用 x0-x5（dst/src 指针 + 4 个临时寄存器），
 *            以及 q0-q15（NEON 寄存器，用于大块拷贝）
 *
 * 以最常见的 16 字节对齐路径为例：
 */
.Lloop_16_byte_aligned:
    ldp     x2, x3, [src, #0]      // 加载 16 字节（两个 64 位寄存器）
    ldp     x4, x5, [src, #16]     // 预加载下一组 16 字节（软件流水线）
    stp     x2, x3, [dst, #0]      // 存储第一组
    stp     x4, x5, [dst, #16]     // 存储第二组
    add     src, src, #32          // 源指针前进 32 字节
    add     dst, dst, #32          // 目标指针前进 32 字节
    subs    count, count, #32      // 剩余长度减 32
    b.gt    .Lloop_16_byte_aligned // 继续循环

关键观察：

• 每轮循环处理 32 字节，仅 7 条指令（4 次内存访问 + 2 次指针更新 + 1 次分支）
• ldp 与 stp 交错排列：加载当前块的同时，后续加载指令已经是下一块的预取 —— 这是经典的软件流水线
• subs + b.gt 组合：单条指令同时完成递减和条件分支（ARM 条件执行特性），节约流水线气泡

4. NEON/SIMD 加速路径（大块拷贝）

对于较大拷贝（通常 > 128 字节），memcpy 会切换到 NEON 寄存器路径：

/*
 * NEON 路径一次可处理 64 字节：
 * 使用 4 个 128-bit NEON 寄存器（q0-q3）
 * 每路加载 16 字节，共 64 字节/轮
 */
.Lneon_loop:
    ld1     {v0.16b, v1.16b, v2.16b, v3.16b}, [src], #64
    st1     {v0.16b, v1.16b, v2.16b, v3.16b}, [dst], #64
    subs    count, count, #64
    b.gt    .Lneon_loop

NEON 路径的收益：

• 每轮 64 字节，仅为 3 条指令（1 加载 + 1 存储 + 1 分支）← 按单指令多数据流（SIMD）一次性搬运
• 相比通用寄存器路径（32 字节/轮），吞吐量翻倍
• 但 NEON 路径存在状态切换开销（保存/恢复 FP/SIMD 寄存器），因此仅在大块拷贝时启用

5. 分支预测优化

memcpy.S 使用了一种分层决策树来最小化分支误预测惩罚：

check size:
    size <= 16  → .Ltiny           (直接展开, 0~15 字节)
    size <= 32  → .Lsmall          (少量 ldp/stp)
    size <= 64  → .Lmedium         (中等展开)
    size > 64   → check alignment  (对齐判定)
        aligned  → .Laligned_main  (主循环, 通用寄存器)
        large    → .Lneon_path     (SIMD 加速)

这种设计确保每个路径的分支数量最少，且热点路径（64~几 KB 区间）的预测准确率最高。

💡 与 memcpy vs movdir64b 对比分析

回到用户提供的 NVMe 场景，理解 ARM64 memcpy 的高性能有助于解释为何 movdir64b（x86 指令）可能不带来收益：

在 NVMe 提交命令的场景中，sizeof(struct nvme_command) = 64 字节，这是一个非常小的拷贝。ARM64 memcpy 对这种尺寸的拷贝：

1. 走的是展开的 .Lsmall / .Lmedium 路径，无循环开销
2. ldp/stp 指令对可以实现单周期吞吐
3. 数据很可能会停留在 L1 cache 中，NVMe 控制器随后通过 DMA 读取

如果使用类似 movdir64b 的 non-temporal 写语义，反而可能：

• 导致数据不进入 cache，后续如果 CPU 需要读回则产生 cache miss
• 对于 64 字节的小拷贝，non-temporal 的固定延迟（64 字节写合并）可能比 cacheable 写更长

💡 收益效果（ARM64 memcpy 性能数据）

根据 ARM 官方文档及内核社区测试（ARM Cortex-X 系列 / Neoverse 平台）：

关键结论：ARM64 内核的 memcpy 在 64 字节这种小尺寸上已达到接近硬件理论极限的性能。优化空间极小。

💡 关于用户场景的建议

对于 NVMe SQ 提交的优化，性能瓶颈不太可能在 memcpy 本身，更可能在于：

1. spin_lock 竞争：多核争抢 sq_lock 的开销通常远大于拷贝本身
2. Doorbell 寄存器写（nvme_write_sq_db）：MMIO 写涉及 PCIe 事务，延迟在微秒级别
3. mpam / cache 一致性协议：memcpy 写完后，NVMe 控制器通过 DMA 读取 SQ —— 这里涉及 cache 一致性嗅探的开销

建议排查方向：

• 使用 perf stat 看 spin_lock 的自旋时间占比
• 检查 writel（doorbell 写）的开销
• 评估是否可以将 SQ 提交与 doorbell 写分离（batch 提交）

  参考来源

• 来源: https://lwn.net/Articles/1022718/