Posts on Hellokitty's Blog

CUDA Event：GPU 时间线上的事件、同步原理与实战

Mon, 31 Aug 2026 10:30:00 +0800

CUDA kernel launch 通常是异步的：CPU 把 kernel、内存拷贝等操作提交到 stream 后便继续执行。由此产生两个常见问题：如何准确测量 GPU 工作耗时，以及如何让不同 stream 在不阻塞 CPU 的情况下建立依赖？

CUDA Event 就是解决这类问题的基础设施。它可以理解为插入 GPU stream 时间线中的一个标记：当 event 之前的工作全部完成，event 才进入完成状态。借助这个状态，我们可以做 GPU 计时、CPU 等待、跨 stream 同步和异步资源回收。

1. Event 不是 CPU 事件，而是 GPU 时间线标记

一个 CUDA stream 是按序执行的 GPU 工作队列：

CPU 提交： Kernel A → memcpy → Event E → Kernel B
                         异步提交

GPU 执行： Kernel A ── memcpy ── E 完成 ── Kernel B

调用 cudaEventRecord(event, stream) 时，CPU 通常只是向 stream 提交一个 event 记录操作，并不会等待 GPU 执行到该位置。只有当这个 stream 中排在 event 前面的操作完成后，event 才会被标记为完成。

SGLang 双 Stream 重叠调度：如何把 CPU 后处理藏到 GPU 计算背后

Sun, 30 Aug 2026 23:09:10 +0800

大模型自回归推理看起来是纯 GPU 工作：每一步做一次模型前向，采样一个 token，再把 token 喂给下一步。然而在高性能推理系统里，GPU 计算只是流水线的一部分。采样结果回传、EOS 判断、请求回收、KV Cache 管理、下一批组装和元数据准备，都可能在两次前向之间制造空洞。

SGLang 的 Overlap Scheduling 解决的正是这个问题。它不是简单地“多开一条 CUDA stream”，而是同时完成两件事：

让当前步产生的 token 留在 GPU，直接作为下一步输入，解除下一次 forward 对 CPU 读值的依赖；
用 scheduler stream 和 engine stream 构造软件流水线，让 GPU 计算当前批次时，调度器处理上一批次的结果。

本文以 Mini-SGLang 的 python/minisgl/scheduler/scheduler.py 为线索，解释 overlap_loop、_forward 和 _process_last_data 背后的依赖重排。

先看结论：优化的不是“提交速度”，而是依赖关系

CUDA kernel 的提交本来就是异步的。CPU 把工作放进 stream 后，不必等待 GPU 完成。因此一个自然的问题是：只用一条 stream，只要 CPU 提交得足够快，不也能让 GPU 连续工作吗？

如果系统只有计算任务，这个判断基本成立。但自回归推理存在一个控制依赖：调度器通常要知道采样出的 token，才能判断请求是否命中 EOS、是否应该释放资源，以及下一轮有哪些请求仍应留在 batch 中。

串行执行会形成如下链条：

GPU:  forward(B1) ── idle ── forward(B2) ── idle ── forward(B3)
CPU:               处理 B1                 处理 B2
                   读 token                读 token
                   判 EOS                  判 EOS
                   组 B2                   组 B3

GPU 完成 B1 后，CPU 才读取结果并决定 B2。此时 GPU 没有可执行的新工作，只能等待。这不是 CPU 调用 CUDA API 太慢，而是 B2 在逻辑上依赖 B1 的结果。

SAC：面向稀疏注意力大模型的 CXL 解耦 KV Cache 系统

Fri, 28 Aug 2026 17:30:00 +0800

本文翻译并整理自论文 SAC: Disaggregated KV Cache System for Sparse Attention LLMs with CXL（arXiv:2606.19746v1，2026 年 6 月 18 日）。原论文采用 CC BY 4.0 许可。为适应博客阅读，本文省略参考文献列表中的完整出版信息，但保留正文结构、关键论证、实验结果与附录要点。

随着大模型进入长上下文与稀疏注意力时代，推理系统的主要瓶颈正从算力转向内存容量。传统 RDMA 解耦 KV Cache 系统会在解码前把完整前缀 KV Cache 搬回本地；但稀疏注意力每一步只访问少量 top-k 条目，这种“全量搬运、少量使用”的方式会同时浪费网络带宽和本地内存。

SAC 的核心思路是：使用 CXL 的低延迟、缓存行粒度 load/store 语义，把 KV Cache 留在解耦内存池中，只在计算时按需读取被选中的 top-k 条目。论文在 DeepSeek-V3.2 与 SGLang 上的实验显示，相比 RDMA 基线，SAC 可实现最高约 2.1 倍吞吐量、9.7 倍更低的 TTFT，以及 1.8 倍更低的 TBT。

摘要

大模型向长上下文推理扩展，使服务系统的主要瓶颈从计算能力转向内存容量。面向稠密注意力模型的传统方案通常采用基于 RDMA 的解耦内存池，在解码开始前，以粗粒度方式将整个前缀 KV Cache 从远端存储取回本地内存。

然而，这种方法并不适合新兴的稀疏注意力模型。解码过程中虽然只有很少一部分 KV 条目真正活跃，系统仍然要把完整 KV Cache 拉回本地，从而造成严重的传输瓶颈和本地内存浪费。

Mooncake 中的协程：从 coro_rpc 到同步接口桥接

Fri, 28 Aug 2026 14:55:00 +0800

Mooncake 确实使用了协程，但它并不是把整个系统改造成“全异步架构”。截至本文分析的主分支提交 3d1665a，协程主要出现在控制面 RPC、连接管理和阻塞任务卸载等 I/O 密集路径；对外接口仍大量保留同步调用形式。

这形成了一个很实用的分层：内部用 C++20 协程组织异步流程，边界处再按需要转换成同步返回值或回调。

技术栈

Mooncake 的协程代码主要建立在两层库之上：

async_simple::coro::Lazy<T> 表示一个惰性异步任务；
yalantinglibs 的 coro_rpc 和 coro_io 提供异步 RPC、网络连接与线程池调度。

典型代码形态如下：

async_simple::coro::Lazy<Result> request() {
    auto response = co_await client.send_request(...);
    co_return response;
}

Lazy<T> 创建后通常不会立刻执行。它需要被另一个协程 co_await，通过 .start(...) 启动，或者由 syncAwait(...) 驱动至完成。

路径一：Mooncake Store 的 Master RPC

mooncake-store/src/master_client.cpp 中的 MasterClient::invoke_rpc 是最清晰的例子。它的外部签名是同步的：

tl::expected<ReturnType, ErrorCode>
MasterClient::invoke_rpc(Args&&... args);

函数内部却先构造 Lazy，再连续等待两个异步阶段：

return async_simple::coro::syncAwait(
    [&]() -> async_simple::coro::Lazy<
                tl::expected<ReturnType, ErrorCode>> {
        auto pending = co_await pool->send_request(
            [&](coro_io::client_reuse_hint,
                coro_rpc::coro_rpc_client& client) {
                return client.send_request<ServiceMethod>(...);
            });

        if (!pending.has_value()) {
            co_return tl::make_unexpected(ErrorCode::RPC_FAIL);
        }

        auto result = co_await std::move(pending.value());
        co_return result->result();
    }());

这里有两次 co_await：

tiny-llm：在 Apple Silicon 上从 Transformer 算子走到推理系统与 Agent

Thu, 27 Aug 2026 15:10:20 +0800

如果你已经知道 Transformer 的基本结构，却仍然不清楚 vLLM 一类推理系统为什么需要 KV Cache、Continuous Batching、Paged Attention，以及这些技术最终如何支撑 Agent，skyzh/tiny-llm 是一条很好的动手路径。

它不是一个追求生产可用的迷你框架，而是一门以 Qwen3 和 MLX 为载体的系统课程：先用可读的数组运算实现模型，再围绕真实性能瓶颈写 Metal 内核，随后搭出动态批处理和分页缓存，最后把同一个本地模型接入带工具、检查点、压缩、评测和分支选择的 Agent 循环。

截至 2026 年 8 月 27 日，项目约有 4.5k stars，使用 Apache-2.0 许可证。课程主体分为四周，已覆盖从注意力到受控 Agent 的完整主线。

项目定位：不是“再写一个 Transformer”

很多教学项目止步于“加载权重并生成一句话”。tiny-llm 的不同之处，是把模型实现当作起点，而不是终点。

它试图回答三个递进的问题：

一个现代开源模型如何由矩阵运算变成文本？
一个正确但缓慢的实现，如何通过测量和内核优化接近成熟框架？
一个推理引擎如何进一步成为可暂停、可审计、可恢复的 Agent 执行器？

项目选择 Apple Silicon、MLX 和 Qwen3。统一内存让 CPU、GPU 和模型权重处在相对简单的硬件环境里；MLX 提供熟悉的 Python 数组接口，同时允许下沉到 Metal；Qwen3 则带有 GQA、QK Norm、BF16 激活和 4-bit 权重，足以暴露真实推理系统中的带宽、注意力与缓存问题。

代码结构刻意分成两套：

src/tiny_llm/ 是学习者逐步补全的实现；
src/tiny_llm_ref/ 是参考实现，用于测试和基准对照；
src/extensions/ 与 src/extensions_ref/ 分别放置 Metal/C++ 扩展；
tests_refsol/ 按周和天组织验收测试；
book/ 是完整课程正文。

这种布局把“阅读—实现—测试—测量”闭成了环。

从朴素循环到硬件极限：GEMM / GEMV 高性能算子优化指南

Wed, 26 Aug 2026 14:20:00 +0800

从 Roofline、数据布局和分层分块出发，逐步分析如何在 CPU 与 GPU 上优化 GEMM/GEMV，并建立可复现的性能验证方法。

NVIDIA Dynamo 源码阅读（二）：分布式运行时如何组织服务与请求

Wed, 26 Aug 2026 13:50:00 +0800

深入 lib/runtime，分析 Namespace、Component、Endpoint、服务发现和网络流水线如何组成 Dynamo 的请求平面。

NVIDIA Dynamo 源码阅读（三）：KV-aware Router 如何选择 Worker

Wed, 26 Aug 2026 13:50:00 +0800

从 token 分块哈希、KV 事件、Radix Tree、负载估计和选择策略出发，拆解 Dynamo KV-aware Router。

NVIDIA Dynamo 源码阅读（四）：Prefill/Decode 分离与 KV 传输

Wed, 26 Aug 2026 13:50:00 +0800

分析 Dynamo 如何进行两阶段路由、交换传输元数据，并让 KV Cache 在 Prefill 与 Decode Worker 之间直接移动。

NVIDIA Dynamo 源码阅读（一）：数据中心级推理栈的整体架构

Wed, 26 Aug 2026 13:50:00 +0800

从请求路径、控制面、数据面和后端边界出发，理解 NVIDIA Dynamo 为什么是推理引擎之上的分布式编排层。

Mini-SGLang 源码阅读（五）：模型层、Tensor Parallel 与自定义 Kernel

Tue, 25 Aug 2026 21:10:00 +0800

从张量并行的矩阵切分原理出发，分析 Mini-SGLang 的并行 Linear、Embedding、模型注册、权重加载和底层 Kernel。

Mini-SGLang 源码阅读（四）：Engine、Attention Backend 与 CUDA Graph

Tue, 25 Aug 2026 21:00:00 +0800

从 GPU 推理的 kernel 启动开销和 Prefill/Decode 差异出发，分析 Mini-SGLang Engine 的完整执行路径。

Mini-SGLang 源码阅读（三）：Paged KV Cache 与 Radix Prefix Cache

Tue, 25 Aug 2026 20:50:00 +0800

从自回归推理的 KV Cache 成本出发，分析 Mini-SGLang 的物理页池、请求页表、前缀匹配与缓存驱逐。

Mini-SGLang 源码阅读（二）：Scheduler、Continuous Batching 与 Chunked Prefill

Tue, 25 Aug 2026 20:40:00 +0800

先解释在线推理调度的资源约束，再分析 Mini-SGLang 如何组织 Prefill、Decode 和 CPU/GPU 重叠执行。

Mini-SGLang 源码阅读（一）：一次 LLM 请求如何穿过推理引擎

Tue, 25 Aug 2026 20:30:00 +0800

从 Prefill、Decode、Continuous Batching 和多进程流水线出发，梳理 Mini-SGLang 一次请求的完整执行流程。

Rust 异步编程原理：Future、状态机、Waker 与 Executor

Tue, 25 Aug 2026 15:35:00 +0800

面向初学者，从 Future::poll 出发推导 Rust async/await 状态机，并解释 Waker、Executor、Reactor、Pin、并发与阻塞。

vLLM 与 Mooncake 对接源码解读：Prefill/Decode 分离中的 KV Cache 如何跨节点传输

Mon, 24 Aug 2026 16:58:43 +0800

深入分析 vLLM 内置 MooncakeConnector：从代理拆分请求、Scheduler 元数据、GPU KV Cache 注册，到 Mooncake Transfer Engine 通过 RDMA 将 Prefill KV 直接搬到 Decode 节点。

FMS 2026 深度解读：AI 正在重构内存与存储层级

Mon, 24 Aug 2026 15:14:44 +0800

深入解读 FMS 2026 的五条核心技术主线：High Bandwidth Flash、3D 内存封装、CXL 内存池、PCIe 6.0 液冷 SSD，以及面向 AI 的 NVMe 可运维基础设施。

Phoenix 论文阅读：一种不使用伪缓冲区的 GPU Direct Storage 重构方案

Mon, 24 Aug 2026 14:49:50 +0800

按原论文结构详译 SC'25 论文 Phoenix：解释 NVIDIA GDS 的伪缓冲区问题、基于 ZONE_DEVICE 的 GPU 显存映射、POSIX/io_uring 编程模型，以及本地 NVMe、远程存储、KV Cache 和模型加载实验。

Phoenix 源码解读：把 GPU 显存变成 Linux I/O 可直达的内存

Mon, 24 Aug 2026 14:40:15 +0800

深入解析 xPU-IO/Phoenix：它如何通过内核模块、用户态库和应用适配器，将 SSD 数据直接送入 GPU 显存；并比较 full BAR、staging、batch、stream 等数据路径的实现与取舍。

Mooncake Store 源码阅读（四）：Master 持久化、快照与热备恢复

Mon, 24 Aug 2026 10:40:00 +0800

解读 Mooncake Store Master 的 oplog、snapshot、standby 和租约机制，以及它们如何保护控制面状态。

Mooncake Store 源码阅读（三）：Get、副本选择与淘汰回收

Mon, 24 Aug 2026 10:30:00 +0800

从 GetReplicaList、Replica 状态和批量 Eviction 分析 Mooncake Store 的读取与空间回收。

Mooncake Store 源码阅读（二）：Put 写入链路与对象原子性

Mon, 24 Aug 2026 10:20:00 +0800

沿 RealClient、PutStart、Transfer Engine 和 PutEnd 阅读 Mooncake Store 的完整写入链路。

Mooncake Store 源码阅读（一）：从对象存储接口到控制面与数据面

Mon, 24 Aug 2026 10:10:00 +0800

从源码目录、进程角色和一次请求的路径入手，解释 Mooncake Store 如何把元数据控制与大对象传输分离。

PCIe BAR 深入解析：从设备地址窗口到 DMA 与 GPUDirect Storage

Fri, 21 Aug 2026 16:25:00 +0800

在操作系统驱动、高性能网卡、NVMe SSD 和 GPU 系统中，经常会同时看到 BAR、MMIO、DMA、IOMMU、peer-to-peer DMA、GPUDirect RDMA 和 GPUDirect Storage 等概念。这些名词都与“设备怎样通过 PCIe 交换控制信息和数据”有关，但它们处在不同层次。

最简洁的理解是：

BAR：让 CPU 能够定位并访问 PCIe 设备中的寄存器或显存窗口
DMA：让 PCIe 设备能够主动读取或写入系统内存
P2P DMA：让一个 PCIe 设备直接访问另一个 PCIe 设备暴露的地址空间
GDS：利用 DMA、GPU 内存映射和驱动协作，让存储数据尽量直接进入 GPU 显存

本文从 PCIe 地址空间和事务模型出发，解释 BAR 是如何分配和映射的，驱动为什么通过 BAR 下发命令，DMA 地址为什么不能简单等同于物理地址，以及 GPUDirect Storage 如何把这些机制组合成一条高性能数据路径。

一、先建立 PCIe 系统视图

一个典型服务器的 PCIe 拓扑如下：

                         CPU
                          │
                Memory Controller
                          │
                       Host RAM
                          │
                    Root Complex
                   ┌──────┴──────┐
                   │             │
              PCIe Switch    PCIe Endpoint
              ┌────┴────┐         GPU
              │         │
           NVMe SSD     NIC

CPU 和内存构成主机侧。Root Complex 把 CPU/内存系统连接到 PCIe fabric。NVMe、网卡和 GPU 通常是 Endpoint。PCIe Switch 用于扩展端口和转发事务。

Rust Tokio 深入解析：运行时原理、并发模型与最佳实践

Fri, 21 Aug 2026 11:35:00 +0800

Rust 语言只定义了 Future、async/await 和 Waker 等异步基础设施，并没有在标准库中提供完整的异步运行时。Tokio 补齐了这一层：它提供任务调度器、网络 I/O 驱动、定时器、异步同步原语、异步文件接口以及阻塞任务隔离机制。

如果把 Rust 异步程序比作一座城市：

Future            = 等待执行的工作
Executor/Scheduler = 安排工作在哪个线程运行
I/O Driver         = 监听 socket 是否就绪
Timer Driver       = 管理定时器何时到期
Waker              = 通知某个任务可以继续
Tokio              = 将上述组件组合成运行时

本文不再重复 Future::poll 和状态机的基础推导，而是聚焦 Tokio 本身：runtime 如何启动，任务如何调度，网络 I/O 为什么不会阻塞线程，以及生产代码中应该怎样处理并发、超时、共享状态、CPU 密集任务和优雅退出。

一、Tokio 提供了什么

一个典型 Tokio 应用依赖：

[dependencies]
tokio = { version = "1", features = ["full"] }

full 适合学习和应用开发，但库作者通常应该只启用实际需要的 feature，缩短编译时间并减少依赖面。

Tokio 的主要组成包括：

组件	作用
Runtime	组合调度器、I/O driver 和 timer driver
Task	由 runtime 调度的异步任务
`tokio::net`	TCP、UDP、Unix Socket 等异步网络接口
`tokio::time`	sleep、interval、timeout
`tokio::sync`	channel、Mutex、RwLock、Semaphore、Notify
`tokio::fs`	文件系统异步接口
`spawn_blocking`	将阻塞或 CPU 密集工作移出异步 worker
`select!`	同时等待多个异步分支

需要先建立一个重要认识：

Mooncake Transfer Engine 源码阅读（四）：TENT 下一代架构如何重构传输引擎

Fri, 21 Aug 2026 11:18:00 +0800

Mooncake 仓库同时存在经典 Transfer Engine 和 TENT（Transfer Engine Next）。TENT 不是简单增加一种 Transport，而是重构了 Segment 生命周期、运行时调度、拓扑选择、QoS、故障转移和插件体系。

阅读版本：

Mooncake commit: 777cc7782417b6e554cf7c2d53210d0d8f89f5cc

一、为什么需要下一代引擎

经典 TE 已经支持 RDMA、TCP、NVLink 和多种硬件，但随着后端增加，TransferEngineImpl + MultiTransport + 各 Transport 容易出现几个问题：

Segment 生命周期分散在元数据和后端注册逻辑中；
传输选择主要依赖静态协议与局部规则；
多 rail、拥塞、故障和 QoS 难以统一调度；
不同后端各自维护进度线程和资源模型；
新硬件接入需要理解大量经典内部约定；
请求取消、deadline 和 failover 缺少统一运行时。

TENT 将这些能力上移到 Runtime 层。

二、目录结构

TENT 核心位于：

tent/src/runtime/
├── transfer_engine_impl.cpp
├── segment.cpp
├── segment_manager.cpp
├── segment_registry.cpp
├── segment_tracker.cpp
├── transport_loader.cpp
├── transport_selector.cpp
├── progress_worker.cpp
├── admission_queue.cpp
├── qos_contract.cpp
├── receiver_credit.cpp
├── topology.cpp
├── control_plane.cpp
└── proxy_manager.cpp

外围包括：

Mooncake Transfer Engine 源码阅读（三）：RDMA、TCP 与请求完成状态机

Fri, 21 Aug 2026 11:17:00 +0800

Transfer Engine 的公共 API 很统一，但 RDMA 和 TCP 的实现差异很大。RDMA 需要 MR、QP、WR 和 CQ；TCP 需要连接、lane、消息 framing 和接收端主动拷贝。本文沿源码比较两条路径，并分析 Batch 状态如何完成。

阅读版本：

Mooncake commit: 777cc7782417b6e554cf7c2d53210d0d8f89f5cc

一、Transport 抽象

Transport 基类统一定义：

install / uninstall
registerLocalMemory / unregisterLocalMemory
submitTransfer
getTransferStatus
allocateBatchID / freeBatchID

它还定义 TransferRequest、TransferStatus 和内部 BufferEntry。

公共抽象要求每个后端回答三个问题：

本地内存如何准备为可传输状态；
请求怎样排队和执行；
如何查询每个 task 的最终状态和字节数。

具体连接模型不属于公共 API。

二、RDMA 初始化

RDMA 后端主要位于：

rdma_transport.cpp
rdma_context.cpp
rdma_endpoint.cpp
endpoint_store.cpp
worker_pool.cpp

安装阶段通常完成：

枚举 RDMA devices / ports / GID
  -> 创建每张 HCA 的 context
  -> 建立 PD、CQ 等资源
  -> 启动 worker / poller
  -> 发布 NIC endpoint metadata
  -> 准备 endpoint store

Mooncake 支持多 HCA、多端口和 GPU 内存，因此一个逻辑请求可能被切到多个 rail 上并行发送。

Mooncake Transfer Engine 源码阅读（二）：Segment、内存注册与元数据服务

Fri, 21 Aug 2026 11:16:00 +0800

Mooncake Transfer Engine 的核心抽象不是“远端指针”，而是 Segment + BufferDesc + Metadata。应用注册本地内存后，TE 将地址范围、设备位置和传输协议发布为 Segment 描述，其他节点才能定位并建立连接。

阅读版本：

Mooncake commit: 777cc7782417b6e554cf7c2d53210d0d8f89f5cc

一、为什么不能直接发送指针

一个进程中的地址：

0x7f12...

在另一个进程中通常没有意义。即使两台机器都使用相同数值，它们也不指向同一块物理内存。

高性能传输还需要额外信息：

这是 CPU DRAM 还是 GPU VRAM；
对应哪张 GPU；
是否注册成 RDMA MR；
rkey 和网卡 endpoint 是什么；
是否能用 NVLink、GPU IPC 或 CXL；
节点当前是否存活；
地址区间是否已经注销。

因此 TE 把地址空间包装成 Segment，并通过元数据服务交换描述。

二、`SegmentDesc`

TransferMetadata::SegmentDesc 是远端发现的中心结构，主要承载：

Segment ID
Segment 名称
协议或协议集合
本机 RPC / endpoint 信息
BufferDesc 列表
设备与拓扑信息
后端扩展元数据

可以把一个 Segment 理解成某个 TE 实例公开的可传输地址空间：

Segment: decode-node-7
├── Buffer A: CPU metadata pool, protocol=rdma
├── Buffer B: GPU KV pool, protocol=rdma
└── Buffer C: GPU KV pool, protocol=hip

同一块 GPU buffer 可以被多个后端注册，从而同时支持：

Mooncake Transfer Engine 源码阅读（一）：统一传输 API 与整体架构

Fri, 21 Aug 2026 11:15:00 +0800

Mooncake Transfer Engine（简称 TE）是 Mooncake 数据平面的基础组件。它不负责决定 KV Cache 应该放在哪里，而是提供统一接口，把一段本地内存搬到远端 Segment，或者从远端 Segment 读取到本地内存。

本文基于 Mooncake 官方仓库：

commit: 777cc7782417b6e554cf7c2d53210d0d8f89f5cc
commit date: 2026-08-21

当前仓库同时保留经典 Transfer Engine 和下一代 TENT。前三篇先阅读经典实现，第四篇再分析 TENT 如何重构控制面、调度和传输后端。

一、源码布局

核心目录为 mooncake-transfer-engine/：

路径	作用
`include/transfer_engine.h`	对外 C++ API
`include/transfer_engine_impl.h`	经典实现内部接口
`include/transport/transport.h`	Transport 抽象、请求和状态
`include/transfer_metadata.h`	Segment、Buffer 与元数据接口
`src/transfer_engine.cpp`	公共 API 转发层，同时兼容经典 TE 与 TENT
`src/transfer_engine_impl.cpp`	初始化、内存注册、Segment 与批次管理
`src/multi_transport.cpp`	安装和选择具体 Transport
`src/transport/`	RDMA、TCP、NVLink、NVMe-oF、EFA 等后端
`tent/`	Transfer Engine Next 实现

TE 的经典架构可以概括为：

应用 / Mooncake Store
        │
        ▼
TransferEngine
        │
        ▼
TransferEngineImpl
   ┌────┼──────────────┐
   ▼    ▼              ▼
Metadata  MultiTransport  Batch 生命周期
          │
   ┌──────┼───────────────┐
   ▼      ▼       ▼       ▼
  RDMA   TCP    NVLink   NVMe-oF ...

二、公共 API 是一层门面

TransferEngine 类本身很薄，大多数函数转发给 TransferEngineImpl：

nvidia-fs 源码阅读（三）：文件 I/O、批处理、完成路径与诊断

Fri, 21 Aug 2026 10:47:00 +0800

前两篇分别介绍了 nvidia-fs 的模块结构，以及 GPU virtual address 到 peer DMA address 的映射。本文沿一次 cuFileRead 对应的内核路径，分析文件 I/O 如何提交、完成和清理，并介绍 batch、稀疏文件、RDMA 与 /proc 诊断接口。

阅读版本：

commit: 328d1d8cce1175c013720985c30e123e9a35242c
GDS_VERSION: 2.29.4

一、I/O 入口

nvfs_ioctl() 接收：

NVFS_IOCTL_READ
NVFS_IOCTL_WRITE
NVFS_IOCTL_BATCH_IO

单次读写共用两阶段结构：

nvfs_io_init(op, ioargs)
  -> 验证并构造 nvfs_io

nvfs_io_start_op(nvfsio)
  -> 向目标文件提交真正 I/O

分成两步的意义在于：参数验证、对象引用和资源分配都应在进入异步 I/O 前完成。一旦请求提交，完成回调可能很快发生，初始化不完整会造成竞态。

二、`nvfs_io_init` 做了什么

nvfs_io_init() 是用户参数到内核 I/O 对象的转换层，主要工作包括：

根据文件描述符取得目标 struct file；
检查读写权限；
查找已经注册的 GPU buffer/mgroup；
验证 GPU buffer offset、文件 offset 和长度；
建立影子 page 对应的 iov 或迭代器；
初始化 kiocb、完成函数和统计字段；
为同步、异步和特殊文件系统路径设置标志。

源码还会检查文件系统类型、direct I/O 条件和文件权限。写操作比读操作更复杂，因为它可能涉及文件扩展、页缓存一致性及磁盘空间预分配。

nvidia-fs 源码阅读（二）：GPU 内存注册、影子页与 DMA 映射

Fri, 21 Aug 2026 10:46:00 +0800

上一篇从 nvfs_init()、字符设备和 ioctl 看到了 nvidia-fs 的外部形态。本文进入 GDS direct path 的核心：怎样把用户分配的 GPU virtual address 变成存储设备能够 DMA 的地址，同时又让 Linux 文件 I/O 栈能够携带它。

阅读版本仍为 NVIDIA gds-nvidia-fs：

commit: 328d1d8cce1175c013720985c30e123e9a35242c
GDS_VERSION: 2.29.4

一、问题本质

普通块 I/O 最终围绕 bio_vec、struct page、scatterlist 和 DMA mapping 展开。但 cudaMalloc 得到的是 GPU 虚拟地址，对 Linux 页缓存和块层来说，它并不是普通 CPU 内存页。

驱动需要解决三次“翻译”：

GPU virtual address
  -> NVIDIA P2P page table 中的 GPU physical pages
  -> Linux I/O 栈可携带的影子 struct page
  -> 某个存储 PCIe 设备可使用的 DMA address

三个地址空间不能混为一谈：

nvidia-fs 源码阅读（一）：模块初始化、设备接口与整体架构

Fri, 21 Aug 2026 10:45:00 +0800

nvidia-fs 是 NVIDIA GPUDirect Storage（GDS）的 Linux 内核模块。它不是一种文件系统，而是连接 libcufile、NVIDIA GPU 驱动、Linux 文件 I/O 和支持 GPUDirect 的存储驱动的一层内核协调组件。

这组文章阅读 NVIDIA 官方 gds-nvidia-fs 仓库，采用的版本为：

commit: 328d1d8cce1175c013720985c30e123e9a35242c
GDS_VERSION: 2.29.4
commit date: 2026-06-01

系列分为三篇：

模块初始化、设备接口与整体架构；
GPU 内存注册、页表与 DMA 映射；
文件 I/O、批量请求、完成路径与可观测性。

本文先回答一个问题：加载 nvidia_fs.ko 后，内核里究竟多了什么？

一、源码目录

核心代码都位于 src/：

文件	职责
`nvfs-core.c/.h`	字符设备、ioctl、GPU 内存注册和文件 I/O 主流程
`nvfs-mod.c`	与 NVMe、RDMA 等外部模块动态注册 DMA 回调
`nvfs-mmap.c/.h`	GPU 页对应的影子 `struct page` 和 mmap 管理
`nvfs-dma.c/.h`	block request 到 GPU DMA 地址的映射
`nvfs-batch.c/.h`	批量 I/O 提交与完成
`nvfs-rdma.c/.h`	RDMA 注册信息管理
`nvfs-pci.c/.h`	GPU 与存储设备的 PCIe 拓扑、距离和亲和性
`nvfs-proc.c`、`nvfs-stat.c`	`/proc` 配置、统计和诊断接口
`nvfs-kernel-interface.c`	不同 Linux 内核版本的兼容封装

主线集中在 nvfs-core.c，但真正的数据直达能力是多个文件共同完成的。

GDS、GIDS 与 uGDS 有什么区别：从数据直达、GPU 发起到用户态 NVMe

Thu, 20 Aug 2026 14:05:00 +0800

GDS、GIDS 和 uGDS 的名字非常接近，也都在讨论 GPU 与存储之间的数据通路，因此很容易被理解成同一项技术的三个版本。

实际上，它们解决的是三个不同层面的问题：

GDS 关注数据路径：怎样让存储数据不经 CPU 内存中转，直接进入 GPU 显存；
GIDS 关注控制路径：怎样让 GPU Kernel 自己决定并发起存储请求，减少 GPU 与 CPU 往返；
uGDS 关注软件栈：怎样让 CPU 在用户态直接管理 NVMe 队列，绕过内核 NVMe 驱动与文件系统。

可以先用一句话概括：

GDS 是“数据直达 GPU”，GIDS 是“GPU 主动要数据”，uGDS 是“用户态 CPU 直接驱动 NVMe 把数据送到 GPU”。

本文从请求由谁发起、数据经过哪里、NVMe 命令由谁构造、是否保留文件系统语义等维度，分析三者的区别与联系。更深入的原理可以继续阅读本系列的三篇文章：

一、先区分数据路径与控制路径

理解这三项技术的关键，是不要把“数据经过哪里”和“谁发起 I/O”混为一谈。

数据路径

数据路径描述有效载荷如何移动。例如：

传统路径：SSD → CPU 内存 → GPU 显存
直接路径：SSD ──────────→ GPU 显存

GDS、GIDS 和 uGDS 都希望建立 SSD 与 GPU 显存之间的 DMA 路径，减少 CPU bounce buffer。但“数据不经过 CPU 内存”并不代表“CPU 没有参与”。

uGDS 原理解析：在用户态打通 NVMe SSD 与 GPU 显存

Thu, 20 Aug 2026 13:55:00 +0800

大模型推理正在把存储重新推到系统性能的核心位置。模型权重、KV Cache、Embedding 和训练检查点都可能在 SSD、主存与 GPU 显存之间频繁搬运。传统路径通常要经过文件系统、内核块层、页缓存或用户态中转缓冲区，不但增加 CPU 开销，也让小块 I/O 延迟变得难以控制。

uGDS 是 ScaleX-IO 开源的一套用户态 GPU Direct Storage 开发库。它的核心思路很直接：

让 CPU 在用户态构造 NVMe 命令并管理提交队列与完成队列，由 SSD 通过 PCIe P2P DMA 直接读写 GPU 显存，从数据路径中绕开内核 NVMe 驱动和文件系统。

本文结合 uGDS 当前源码，解释它为什么快、一次 I/O 如何执行、内核模块与用户态库如何分工，以及使用这类“绕过内核”的存储栈时必须承担哪些工程责任。

一、uGDS 想解决什么问题

先看一条常见的数据读取路径：

NVMe SSD
   │
   ▼
内核 NVMe 驱动 → 块层 → 文件系统
   │
   ▼
主机内存缓冲区
   │
   ▼
GPU 显存

即使系统支持 Direct I/O，应用仍然通常要进入内核，由内核驱动准备 NVMe 命令、完成 DMA 映射并处理中断或轮询。若数据还要经过主机内存，再复制到 GPU，路径会更长。

NVIDIA GPU-Initiated Data Storage（GIDS）详解：让 GPU Kernel 主动访问存储

Wed, 19 Aug 2026 14:05:00 +0800

GPUDirect Storage（GDS）已经能够让存储数据绕过 CPU 内存，直接进入 GPU 显存。但经典 GDS 仍有一个重要特征：I/O 请求由 CPU 侧应用代码提交。

当 GPU kernel 在执行过程中才知道下一份数据位于哪里时，控制权必须在 GPU 与 CPU 之间往返。对于图计算、向量检索、稀疏模型和超大规模数据分析，这种细粒度同步可能比数据传输本身更昂贵。

NVIDIA GPU-Initiated Data Storage，简称 GIDS，试图进一步消除这层控制瓶颈：让 GPU kernel 直接发起存储 I/O，使 GPU 不仅是数据的接收者，也是 I/O 请求的生产者。

本文介绍 GIDS 的动机、架构、工作流程、适用场景，以及它和 GDS 的本质区别。

一、为什么有了 GDS 还需要 GIDS

GDS 优化了数据路径：

CPU 发起请求
     │
     ▼
存储 ─────────────► GPU 显存
       数据不经过 CPU 内存

这已经消除了大量主机内存中转，但控制路径仍然经过 CPU。经典流程可能是：

GPU 执行 kernel；
GPU 产生下一批要访问的数据索引；
kernel 结束或与 CPU 同步；
CPU 读取结果并构造文件 I/O；
CPU 调用 cuFile；
数据进入 GPU；
CPU 再次启动 kernel。

如果每次请求都是大块、批量且可提前预测，这种方式通常没有问题。但如果 GPU 在计算过程中产生数以万计甚至更多的动态访问，频繁的 GPU—CPU 往返会带来：

NVIDIA GPUDirect Storage（GDS）详解：让存储数据绕过 CPU 直达 GPU

Wed, 19 Aug 2026 14:00:00 +0800

在 AI 训练、科学计算和数据分析系统中，GPU 的算力越来越强，但数据从存储设备进入 GPU 的路径却可能成为瓶颈。传统 I/O 通常要先把数据读入 CPU 内存，再复制到 GPU 显存，不仅增加内存带宽消耗，还让 CPU 承担大量数据搬运工作。

NVIDIA GPUDirect Storage，简称 GDS，解决的正是这个问题：它在存储设备与 GPU 显存之间建立更直接的数据路径，使应用能够通过 cuFile API 将文件数据读入 GPU 缓冲区，减少 CPU bounce buffer 和不必要的数据复制。

本文介绍 GDS 的工作原理、软件栈、典型使用方式、适用场景以及它与 GPU-Initiated Data Storage（GIDS）的关系。

一、传统 GPU I/O 为什么效率不高

传统文件读取到 GPU 的路径大致如下：

NVMe / 文件系统
       │
       ▼
CPU 内存缓冲区
       │ cudaMemcpy
       ▼
GPU 显存

应用通常先调用 read、pread 或异步 I/O 接口，把文件内容读入主机内存，然后再调用 CUDA memcpy 将数据复制到 GPU。

这条路径存在几个问题：

同一份数据先经过 CPU 内存，再进入 GPU 显存；
存储流量和 GPU 传输流量竞争 CPU 内存带宽；
CPU 需要提交、管理和完成数据搬运；
大规模 GPU 系统中，CPU 和内存通道容易成为共享瓶颈；
应用需要维护主机端 staging buffer，并处理双重缓冲。

当 GPU 计算越来越快、单机挂载更多 NVMe 或更高速的并行文件系统后，这些额外开销会更加明显。

数据库 MVCC 原理与实现：版本链、事务快照和可见性判断

Fri, 14 Aug 2026 23:50:00 +0800

MVCC（Multi-Version Concurrency Control，多版本并发控制）是现代数据库实现高并发事务的重要机制。它的核心思想并不复杂：数据被修改时，不立即丢弃旧值，而是保留多个版本；事务读取数据时，根据自己的快照选择可见版本。

因此，读事务可以继续访问旧版本，写事务则创建新版本。普通读取通常不需要等待并发写入完成，写入也不必等待读事务释放共享锁。

本文从 MVCC 要解决的问题出发，依次说明版本存储、事务快照、可见性判断、写冲突控制和旧版本回收，并比较 InnoDB 与 PostgreSQL 的典型实现。

一、为什么需要 MVCC

假设数据库中存在一条记录：

账户 A 的余额 = 100

事务 T1 正在读取这条记录，与此同时，事务 T2 希望把余额修改为 80。

如果所有读取都依赖共享锁，那么 T2 可能必须等待 T1 结束；如果 T2 已经持有排他锁，T1 又可能必须等待 T2。锁能够保证正确性，但大量读写互相等待会降低系统并发能力，并增加死锁概率。

MVCC 使用另一种思路处理普通读取：

新版本：balance = 80，由 T2 创建
                 ↓
旧版本：balance = 100

如果 T1 的事务快照不允许它看到 T2 的修改，T1 就读取旧版本 100；在 T2 提交后启动的新事务，则可以读取新版本 80。

于是，同一时刻可以出现：

旧事务看到 100
新事务看到 80

这不是数据不一致，而是两个事务观察到了数据库在不同逻辑时刻的一致状态。

二、MVCC 的五个组成部分

一个完整的 MVCC 实现通常包含五个部分：

MVCC = 多版本存储
     + 事务快照
     + 可见性判断
     + 写冲突控制
     + 旧版本回收

只保存历史版本还不够。数据库还必须知道版本由谁创建、事务能够看到哪些版本、两个写事务冲突时如何处理，以及历史版本何时可以安全删除。

3FS 如何使用 FoundationDB：元数据模型、事务与并发控制

Fri, 14 Aug 2026 19:10:00 +0800

3FS 是面向 AI 训练和推理负载设计的分布式文件系统。它没有把 FoundationDB 当成普通的持久化 KV 使用，而是围绕 FoundationDB 的有序键空间、乐观事务、冲突检测和 Versionstamp，构建了一套强一致的文件系统元数据服务。

本文从源码出发，梳理 3FS 如何接入 FoundationDB，如何编码 inode 和目录项，以及 create、rename、remove、list 等文件系统操作怎样映射为 FoundationDB 事务。

本文分析的源码位于 3FS 仓库中的以下目录：

src/fdb/             FoundationDB C API 封装
src/common/kv/       通用 KV 和事务接口
src/meta/store/      inode、目录项和元数据操作
src/meta/components/ ID 分配、服务分布和 GC 等组件
src/meta/service/    Meta Service RPC 入口

一、3FS 中 FoundationDB 的定位

3FS 将数据面和元数据面分开：

文件的 chunk 数据由 Storage Service 保存。
文件系统元数据由 Meta Service 管理，并持久化到 FoundationDB。

FoundationDB 中保存的主要内容包括：

inode；
directory entry，也就是目录项；
文件打开会话；
RPC 幂等记录；
Meta Server 分布信息；
用户、配置和其他全局状态。

整体调用链可以简化为：

FoundationDB 事务如何实现？从源码看 GRV、Resolver、TLog 与 Storage Server

Fri, 14 Aug 2026 17:00:00 +0800

FoundationDB 支持跨任意 key range 的 ACID 事务，并向应用提供严格可串行化语义。但它既没有让每个 Storage Server 参与经典的两阶段提交，也不是传统单机数据库中“共享缓冲池 + Undo/Redo”的事务实现。

它的核心方案可以概括为：

全局版本号 + MVCC 快照读 + 客户端暂存修改 + Resolver 乐观冲突检测 + 多副本 TLog 持久化。

本文结合 FoundationDB 官方源码，沿着一笔事务的完整路径，解释它如何从读取、提交、冲突检测，一直走到日志持久化和 Storage Server 应用。

本文分析的源码版本为：

commit: eab21ffe07c20575d5bac9ab0745375b8f7f8357
date:   2026-08-12

源码中的具体行号会随版本变化，阅读时应以函数和类型名为主要定位依据。

一、整体架构

FoundationDB 的事务涉及以下核心角色：

角色	主要职责
Client	保存事务 mutations、读冲突范围和写冲突范围
GRV Proxy	分配 Read Version
Commit Proxy	批量接收事务、分配 Commit Version、组织提交流水线
Resolver	检测乐观事务冲突
TLog	复制并持久化已提交 mutations
Storage Server	提供版本化读取，异步应用 TLog mutations
Sequencer	为事务系统提供版本推进基础

完整流程可以简化为：

Client
  │
  ├── 获取 Read Version
  │
  ├── 从 Storage Server 读取该版本
  │
  ├── 在客户端积累 mutations 和 conflict ranges
  │
  └── 提交
        │
        ▼
   Commit Proxy
        │
        ├── 组成 Commit Batch
        ├── 分配 Commit Version
        └── 按 key range 发给 Resolver
        │
        ▼
     Resolver
        │
        ├── 检查 read conflict ranges
        ├── 登记 write conflict ranges
        └── 返回 committed / conflict / too old
        │
        ▼
   Commit Proxy
        │
        ├── 丢弃冲突事务
        ├── 为 mutation 添加 Storage Server tag
        └── 将成功事务写入 TLog
        │
        ▼
       TLog
        │
        ├── 按冗余策略复制和持久化
        └── 返回 durable
        │
        ▼
   Commit Proxy
        │
        └── 向 Client 返回 Commit Version
        │
        ▼
 Storage Server
        ├── 异步读取自己的 tagged mutations
        ├── 应用到内存中的版本化数据
        └── 后台持久化到 Storage Engine

最关键的解耦是：

FoundationDB 中有 Undo 和 Redo 吗？从 TLog、MVCC 到故障恢复

Fri, 14 Aug 2026 10:00:00 +0800

传统数据库通过 Undo Log 和 Redo Log 保证事务的原子性与持久性：Undo 撤销未提交的修改，Redo 恢复已经提交但尚未写入数据文件的修改。那么，在采用分布式事务架构的 FoundationDB 中，是否也存在这两类日志？

简短回答是：

FoundationDB 有承担类似 Redo 职责的 TLog，但通常没有传统意义上的 Undo Log。

这并不意味着 FoundationDB 不支持事务回滚或 MVCC，而是因为它对未提交数据、提交日志和历史版本的组织方式与传统数据库不同。

一、先回顾传统数据库为什么需要 Undo 和 Redo

传统数据库通常允许事务直接修改缓冲池中的共享数据页。数据页何时写入磁盘，与事务何时提交并不完全同步。

因此会出现两种状态。

1. 事务未提交，数据页却已经落盘

例如事务把账户余额从 100 改成 80，但随后事务失败：

BEGIN;

UPDATE account
SET balance = 80
WHERE id = 'A';

ROLLBACK;

如果包含 80 的脏页已经写入磁盘，数据库就必须知道原值是 100，才能撤销这次修改。这是 Undo Log 的主要职责。

2. 事务已经提交，数据页却尚未落盘

另一个事务已经执行 COMMIT，但修改可能仍然只存在于内存中的脏页里。如果服务器此时断电，已提交的数据就会丢失。

因此数据库先持久化 Redo Log，再返回提交成功。重启后，即使数据页没有及时落盘，也可以通过 Redo 重新应用修改。

可以把二者概括为：

Undo：事务不应该生效，但修改可能已经进入数据文件。
Redo：事务应该生效，但修改可能还没有进入数据文件。

二、FoundationDB 的事务提交流程

FoundationDB 并不是把客户端事务中的每次 set 或 clear 立即写入 Storage Server。事务提交前，这些操作首先保存在客户端的事务对象中。

哈希碰撞概率与生日界：从公式到 SHA-256 / XXH128 实测

Tue, 11 Aug 2026 15:10:00 +0800

选哈希算法时常有两个问题绑在一起：碰撞概率有多小、算得有多快。这篇把碰撞概率背后的数学（生日界）讲清楚，再用它算一算 256-bit 的 SHA-256/BLAKE3 与 128-bit 的 XXH128 各自的碰撞概率，最后附上一组本机实测速度数据。

本文所有实测数据均来自随机生成的字节串，不含任何业务或私有数据。

一、背景：碰撞概率的两种含义

对固定长度输出的哈希，“碰撞概率"必须分两种场景谈，否则会得出互相矛盾的结论：

随机碰撞：没有攻击者，数据是正常/随机的。这时只要输出在取值空间里均匀分布，碰撞概率就纯粹由输出位数决定，与具体算法无关。
抗恶意碰撞：有攻击者知道算法、故意构造两个哈希相同的输入。这里才真正区分加密哈希（SHA-256、BLAKE3、BLAKE2）和非加密哈希（xxHash、CityHash、Murmur）。

第一种是数学问题，用生日界就能算。第二种是密码学性质，非加密哈希直接不提供保证。

二、生日问题：直觉的陷阱

一个房间里要多少人，才有超过 50% 的概率存在两人同一天生日？答案是 23 人——远比直觉小。原因在于碰撞看的不是"某人和我同天”，而是"任意两人之间"的配对数：n 个人有 n(n-1)/2 ≈ n²/2 对，概率随 n² 增长。

哈希碰撞是同一个问题：把"人"换成"哈希输入"，把"365 天"换成"哈希空间大小 N"。对 128-bit 哈希，N = 2^128。

三、生日界公式的推导

设哈希空间大小为 N，独立均匀地放入 n 个值。直接算"至少一次碰撞"要用容斥，很麻烦，所以反过来算"全部不同"的概率：

第 1 个：随便放         → N/N
第 2 个：不能撞前 1 个  → (N-1)/N
...
第 n 个：不能撞前 n-1 个 → (N-n+1)/N

全部不同的概率是连乘：

P(无碰撞) = ∏_{k=0}^{n-1} (1 - k/N)

于是至少一次碰撞：

P(碰撞) = 1 - ∏_{k=0}^{n-1} (1 - k/N)

这是精确解，但连乘不好用。用近似 1 - x ≈ e^(-x)（x 很小时成立）把每一项换掉：

Posts on Hellokitty's Blog

CUDA Event：GPU 时间线上的事件、同步原理与实战

1. Event 不是 CPU 事件，而是 GPU 时间线标记

SGLang 双 Stream 重叠调度：如何把 CPU 后处理藏到 GPU 计算背后

先看结论：优化的不是“提交速度”，而是依赖关系

SAC：面向稀疏注意力大模型的 CXL 解耦 KV Cache 系统

摘要

Mooncake 中的协程：从 coro_rpc 到同步接口桥接

技术栈

路径一：Mooncake Store 的 Master RPC

tiny-llm：在 Apple Silicon 上从 Transformer 算子走到推理系统与 Agent

项目定位：不是“再写一个 Transformer”

从朴素循环到硬件极限：GEMM / GEMV 高性能算子优化指南

NVIDIA Dynamo 源码阅读（二）：分布式运行时如何组织服务与请求

NVIDIA Dynamo 源码阅读（三）：KV-aware Router 如何选择 Worker

NVIDIA Dynamo 源码阅读（四）：Prefill/Decode 分离与 KV 传输

NVIDIA Dynamo 源码阅读（一）：数据中心级推理栈的整体架构

Mini-SGLang 源码阅读（五）：模型层、Tensor Parallel 与自定义 Kernel

Mini-SGLang 源码阅读（四）：Engine、Attention Backend 与 CUDA Graph

Mini-SGLang 源码阅读（三）：Paged KV Cache 与 Radix Prefix Cache

Mini-SGLang 源码阅读（二）：Scheduler、Continuous Batching 与 Chunked Prefill

Mini-SGLang 源码阅读（一）：一次 LLM 请求如何穿过推理引擎

Rust 异步编程原理：Future、状态机、Waker 与 Executor

vLLM 与 Mooncake 对接源码解读：Prefill/Decode 分离中的 KV Cache 如何跨节点传输

FMS 2026 深度解读：AI 正在重构内存与存储层级

Phoenix 论文阅读：一种不使用伪缓冲区的 GPU Direct Storage 重构方案

Phoenix 源码解读：把 GPU 显存变成 Linux I/O 可直达的内存

Mooncake Store 源码阅读（四）：Master 持久化、快照与热备恢复

Mooncake Store 源码阅读（三）：Get、副本选择与淘汰回收

Mooncake Store 源码阅读（二）：Put 写入链路与对象原子性

Mooncake Store 源码阅读（一）：从对象存储接口到控制面与数据面

PCIe BAR 深入解析：从设备地址窗口到 DMA 与 GPUDirect Storage

一、先建立 PCIe 系统视图

Rust Tokio 深入解析：运行时原理、并发模型与最佳实践

一、Tokio 提供了什么

Mooncake Transfer Engine 源码阅读（四）：TENT 下一代架构如何重构传输引擎

一、为什么需要下一代引擎

二、目录结构

Mooncake Transfer Engine 源码阅读（三）：RDMA、TCP 与请求完成状态机

一、Transport 抽象

二、RDMA 初始化

Mooncake Transfer Engine 源码阅读（二）：Segment、内存注册与元数据服务

一、为什么不能直接发送指针

二、SegmentDesc

Mooncake Transfer Engine 源码阅读（一）：统一传输 API 与整体架构

一、源码布局

二、公共 API 是一层门面

nvidia-fs 源码阅读（三）：文件 I/O、批处理、完成路径与诊断

一、I/O 入口

二、nvfs_io_init 做了什么

nvidia-fs 源码阅读（二）：GPU 内存注册、影子页与 DMA 映射

一、问题本质

nvidia-fs 源码阅读（一）：模块初始化、设备接口与整体架构

一、源码目录

GDS、GIDS 与 uGDS 有什么区别：从数据直达、GPU 发起到用户态 NVMe

一、先区分数据路径与控制路径

数据路径

uGDS 原理解析：在用户态打通 NVMe SSD 与 GPU 显存

一、uGDS 想解决什么问题

NVIDIA GPU-Initiated Data Storage（GIDS）详解：让 GPU Kernel 主动访问存储

一、为什么有了 GDS 还需要 GIDS

NVIDIA GPUDirect Storage（GDS）详解：让存储数据绕过 CPU 直达 GPU

一、传统 GPU I/O 为什么效率不高

数据库 MVCC 原理与实现：版本链、事务快照和可见性判断

一、为什么需要 MVCC

二、MVCC 的五个组成部分

3FS 如何使用 FoundationDB：元数据模型、事务与并发控制

一、3FS 中 FoundationDB 的定位

FoundationDB 事务如何实现？从源码看 GRV、Resolver、TLog 与 Storage Server

一、整体架构

FoundationDB 中有 Undo 和 Redo 吗？从 TLog、MVCC 到故障恢复

一、先回顾传统数据库为什么需要 Undo 和 Redo

1. 事务未提交，数据页却已经落盘

2. 事务已经提交，数据页却尚未落盘

二、FoundationDB 的事务提交流程

哈希碰撞概率与生日界：从公式到 SHA-256 / XXH128 实测

一、背景：碰撞概率的两种含义

二、生日问题：直觉的陷阱

三、生日界公式的推导

二、`SegmentDesc`

二、`nvfs_io_init` 做了什么