2.2.4 统一虚拟寻址与零拷贝技术 (UVA & Zero-Copy)

一、约束输入与对齐 (Constraints & Alignment)

根据审计结果与硬件特性，我们拥有以下有利条件：

驱动支持 (UVA Ready)：审计显示 iluvatar.ko 模块参数 itr_enable_vmm_va:Y，说明智铠驱动已开启虚拟内存管理，支持 UVA。这意味着 Host 指针可以直接被 GPU Kernel 解引用，无需显式指针转换（cudaHostGetDevicePointer 仍建议调用以确保兼容性，但逻辑上地址空间是统一的）。
物理通道：PCIe 4.0 x8 (或 x16 修复后)。带宽虽高，但** 延迟（Latency）** 仍远高于访问板载显存（VRAM）。
计算特性：雷达信号处理（FFT、滤波）是访存密集型任务，同一个数据点会被多次读取（例如 FFT 的蝶形运算）。

二、权衡分析与选项呈现 (Trade-off Matrix)

我们将数据分为两类场景进行权衡：“小数据/控制流” 与 “大数据/原始回波”。

场景 A：小数据传输（如波控码、雷达参数、状态字）

特征：数据量小（< 4KB），更新频率低，GPU 仅读取一次或极少次。

选项	1. 显式拷贝 (`cudaMemcpyAsync`)	2. 零拷贝直接访问 (Zero-Copy) (推荐)
机制	`Host -> PCIe -> VRAM -> Kernel`	`Kernel -> PCIe -> Host RAM`
启动开销	高。API 调用开销 + DMA 启动开销（约 10-20us）。	零。无 API 调用，Kernel 直接读取指针。
总线效率	低。对于几十字节的数据，DMA 建立连接的成本远超传输本身。	中。虽然单次 PCIe 访问延迟高，但省去了 DMA 启动时间，总体更快。
适用性	不推荐。“杀鸡用牛刀”。	最佳实践。适合传递动态参数结构体。

场景 B：大数据传输（原始回波 I/Q 数据）

特征：数据量大（MB 级），吞吐要求高，Kernel 需反复多次读取同一块数据。

选项	1. 显式拷贝 (`cudaMemcpyAsync`) (推荐)	2. 零拷贝直接访问 (Zero-Copy)
机制	`Host -> DMA(Burst) -> VRAM -> Kernel`	`Kernel -> PCIe(TLP) -> Host RAM`
访存带宽	极高 (VRAM)。HBM/GDDR 带宽（900GB/s+）。	极低 (PCIe)。受限于 PCIe x8/x16（16-32GB/s）。
TLB 风险	无。数据在 VRAM 中物理连续。	高 (TLB Miss)。GPU 需频繁通过 IOMMU 查询 Host 页表，导致流水线停顿。
计算影响	计算核心全速运行，无 IO 等待。	计算核心饥饿。Kernel 算几步就要等几百个时钟周期的 PCIe 数据。

三、基线确立与实施规范

基于上述分析，我们确立 “小数据零拷贝，大数据显式拷贝” 的混合策略基线。

1. 小数据基线：UVA 零拷贝 (Zero-Copy)

针对雷达的控制参数（如 DataContext 中的元数据、当前波束指向信息），我们利用 UVA 特性实现零拷贝。

分配规范：
- 继续使用 cudaMallocHost。
- 必须添加 cudaHostAllocMapped | cudaHostAllocWriteCombined 标志。
  - 注意：WriteCombined (WC) 会禁止 CPU 缓存。这对 CPU 读取极慢，但对 CPU 顺序写入 +GPU 读取性能极佳。因为这些参数通常是 CPU 写一次、GPU 读一次，WC 是绝佳选择。
访问规范：
- CPU 端：直接写入结构体成员。
- GPU 端：将 Host 指针直接传给 Kernel，Kernel 像访问普通显存一样解引用。

2. 大数据基线：显式异步 DMA (Explicit DMA)

针对原始回波数据（即 DataReceiver 传递过来的 Payload），严禁使用零拷贝。

决策：维持 2.2.2 确立的 cudaMemcpyAsync 三级流水线。
论证：
- 带宽瓶颈：雷达信号处理算法（如 FFT）的算术强度（Compute-to-Memory Ratio）通常较低，主要受限于显存带宽。如果让 Kernel 直接跨 PCIe 去读 Host 内存，带宽将从 ~900GB/s 骤降至 ~16GB/s，导致 GPU 算力闲置率高达 98%，这绝对是不可接受的。
- TLB 抖动：大数据量的随机访问（或大跨度访问，如转置）会打爆 IOMMU 的 TLB 缓存，引发严重的性能抖动。

3. 基线实施代码范式

// 1. 小数据 (参数/配置): 使用 Zero-Copy + WriteCombined
struct RadarParams {
    float beam_azimuth;
    float beam_elevation;
    int   waveform_id;
};

RadarParams* h_params;
// 分配时启用 Mapped (UVA) 和 WriteCombined (CPU写优化)
cudaHostAlloc(&h_params, sizeof(RadarParams), 
              cudaHostAllocMapped | cudaHostAllocWriteCombined);

// CPU 写入 (极快，直接进 Write Combine Buffer)
h_params->beam_azimuth = 45.0f;

// GPU Kernel 启动 (直接传指针，无需 Memcpy)
// d_params 可以通过 cudaHostGetDevicePointer 获取，或者在 UVA 下直接用 h_params
process_kernel<<<…>>>(…, h_params); 


// 2. 大数据 (回波): 使用 Explicit Async Copy
// 维持之前确立的 MemoryPool (Pinned) + Stream Async Copy
cudaMemcpyAsync(d_buffer, h_pinned_buffer, size, cudaMemcpyHostToDevice, stream);
process_data_kernel<<<…>>>(…, d_buffer); // Kernel 访问的是高速 VRAM

总结与下一步行动

我们确立了 2.2.4 统一虚拟寻址与零拷贝技术 的基线：

控制流：启用 Zero-Copy (UVA + WC)，消除小数据的传输开销。
数据流：坚守 Explicit DMA (VRAM)，保障计算吞吐量。

现在，我们解决了“怎么传”、“传给谁”、“谁不用传”。只剩最后一个细节：“传多大一块？”

这是 2.2.5 传输粒度与 TLP 效率优化。PCIe 总线传输 1 个字节和传输 128 字节的物理开销（TLP Header）是一样的。如果我们的 DataPacket 切分太碎，PCIe 有效带宽就会打折。我们需要结合您的 01_数据接收模块设计.md 中的 packet_block_size_kb (64KB) 来最后确认这一粒度。

提问：您是否确认 “控制流零拷贝，数据流显式拷贝” 的混合基线？确认后我们进入 2.2.5。

6.3 KiB Raw Blame History Unescape Escape