一个调度标志位的改变，如何让数据库吞吐量瞬间腰斩？

引言：从”完美运行”到”性能腰斩”

想象一下这样的场景：你的数据库服务器刚刚升级了最新的Linux Kernel 7.0，期待着更好的性能和安全性。然而，上线后监控图表却显示了一个触目惊心的画面——PostgreSQL的吞吐量在毫无征兆的情况下骤降了将近一半。

这背后的根源，直指Linux内核调度器在Kernel 7.0中引入的一次重大变更——惰性抢占（PREEMPT_LAZY） 模型¹²。本文将深入技术底层，剖析这次性能衰退的来龙去脉，并探讨其背后的设计哲学冲突。

一、Linux抢占模型速览：吞吐量 vs. 响应时间的权衡

要理解这个问题，我们首先需要明白Linux内核是如何决定”何时暂停一个任务，让另一个任务运行”的。这个决策过程被称为抢占（Preemption）。多年来，Linux内核提供了几种抢占模式，在系统吞吐量和交互响应时间之间做出权衡。

对于绝大多数Linux发行版内核，默认采用的是PREEMPT_VOLUNTARY模式。而像PostgreSQL这样的数据库，则极度依赖于PREEMPT_NONE或PREEMPT_VOLUNTARY带来的高吞吐量特性。

下图展示了不同抢占模型在性能特性上的定位：

graph LR
    subgraph "抢占模型的演化与权衡"
        A[PREEMPT_NONE<br/>服务器优化] -->|引入检查点| B[PREEMPT_VOLUNTARY<br/>折中方案]
        B -->|全面可抢占| C[PREEMPT_FULL<br/>桌面优化]
        C -->|硬实时| D[PREEMPT_RT<br/>实时系统]
        B -.->|v7.0新增| E[PREEMPT_LAZY<br/>简化内核]
    end
    
    style A fill:#90EE90
    style B fill:#FFD700
    style C fill:#FFB6C1
    style D fill:#FF6347
    style E fill:#87CEEB
    
    classDef throughput fill:#90EE90,stroke:#333,stroke-width:2px
    classDef latency fill:#FFB6C1,stroke:#333,stroke-width:2px
    classDef balanced fill:#FFD700,stroke:#333,stroke-width:2px
    classDef newmodel fill:#87CEEB,stroke:#333,stroke-width:3px

关键特性对比：

• 🟢 PREEMPT_NONE/VOLUNTARY：高吞吐，PostgreSQL的最佳拍档
• 🔵 PREEMPT_LAZY：试图保持高吞吐，同时简化内核
• 🔴 PREEMPT_FULL/RT：低延迟优先，牺牲部分吞吐

cond_resched()：一个权宜之计

在PREEMPT_NONE模式下，如果一个内核线程执行了过长的循环，可能会导致其他任务”饿死”。为了解决这个问题，内核开发者在代码中插入了数百个cond_resched()调用³。这就像在高速公路上设置的临时检查站——内核线程运行到这里时，会主动”看一眼”是否有更高优先级的任务需要CPU，如果有，就主动让出。

但这终究是一个启发式（heuristic）的权宜之计：它依赖于开发者”猜”对哪里需要插入检查点，而且这些额外的检查点本身也会带来性能开销。

二、Kernel 7.0 的改变：惰性抢占的登场

Kernel 7.0 的调度器迎来了一次重大重构。维护者Peter Zijlstra引入了一个新的抢占模式——PREEMPT_LAZY（惰性抢占）。在commit 7dadeaa6e851中，他详细解释了引入这一机制的三个核心原因²：

The introduction of PREEMPT_LAZY was for multiple reasons:

• PREEMPT_RT suffered from over-scheduling, hurting performance compared to !PREEMPT_RT.
• the introduction of (more) features that rely on preemption; like folio_zero_user() which can do large memset() without preemption checks.
• the endless and uncontrolled sprinkling of cond_resched() – mostly cargo cult or in response to poor to replicate workloads.

简单来说，核心目标是简化内核代码，并为最终移除所有的cond_resched()铺平道路。

在支持PREEMPT_LAZY的架构（包括x86和ARM64）上，传统的PREEMPT_VOLUNTARY选项已从配置菜单中移除⁴。在kernel/Kconfig.preempt中可以看到：

config PREEMPT_VOLUNTARY
	bool "Voluntary Kernel Preemption (Desktop)"
	depends on !ARCH_HAS_PREEMPT_LAZY
	depends on !ARCH_NO_PREEMPT

技术核心：两个标志位的故事

PREEMPT_LAZY的实现非常巧妙，它引入了两个关键的线程标志位。在commit 26baa1f1c4bd中，Peter Zijlstra描述了这一基础设施⁵：

Add the basic infrastructure to split the TIF_NEED_RESCHED bit in two. Either bit will cause a resched on return-to-user, but only TIF_NEED_RESCHED will drive IRQ preemption.

具体来说：

1. TIF_NEED_RESCHED（紧急标志）：设置此标志意味着必须立即抢占当前任务。这通常用于高优先级实时任务被唤醒的场景。
2. TIF_NEED_RESCHED_LAZY（惰性标志）：设置此标志意味着”最好”抢占当前任务，但不是现在。这用于普通的调度公平性考虑。

在commit 7c70cb94d29c中，Peter Zijlstra进一步说明了工作机制⁶：

This LAZY bit will be promoted to the full NEED_RESCHED bit on tick. As such, the average delay between setting LAZY and actually rescheduling will be TICK_NSEC/2.

In short, Lazy preemption will delay preemption for fair class but will function as Full preemption for all the other classes, most notably the realtime (RR/FIFO/DEADLINE) classes.

工作机制：

• 大多数情况：当一个普通的高优先级任务被唤醒时，调度器只会设置TIF_NEED_RESCHED_LAZY标志，而不是传统的TIF_NEED_RESCHED。
• 检查点行为改变：在PREEMPT_VOLUNTARY模式下，cond_resched()会检查TIF_NEED_RESCHED标志并立即让出CPU。但在新的惰性模式下，cond_resched()不再检查惰性标志。
• 最终抢占：当前任务会继续运行，直到下一个时钟中断（timer tick） 到来。此时，内核会检查惰性标志，如果被设置，则将其”升级”为紧急标志，并触发抢占。

内核在kernel/sched/core.c中实现了这一机制：

static __always_inline int get_lazy_tif_bit(void)
{
	if (dynamic_preempt_lazy())
		return TIF_NEED_RESCHED_LAZY;

	return TIF_NEED_RESCHED;
}

void resched_curr_lazy(struct rq *rq)
{
	__resched_curr(rq, get_lazy_tif_bit());
}

在时钟中断处理中，惰性标志会被升级为常规的重调度标志：

	if (dynamic_preempt_lazy() && tif_test_bit(TIF_NEED_RESCHED_LAZY))
		resched_curr(rq);

改变前后的对比

Kernel 6.x (PREEMPT_VOLUNTARY)：高优先级任务醒来 → 设置 TIF_NEED_RESCHED → 当前任务运行到下一个cond_resched() → 立即让出CPU。

Kernel 7.0 (PREEMPT_LAZY)：高优先级任务醒来 → 设置 TIF_NEED_RESCHED_LAZY → 当前任务忽略所有cond_resched()检查点 → 继续运行直到时钟中断（例如几毫秒后）→ 升级标志，让出CPU。

下面的时序图展示了这两种模式的关键差异：

sequenceDiagram
    participant TS as 任务调度器
    participant CT as 当前任务
    participant CP as cond_resched()
    participant TI as 时钟中断
    
    Note over TS,TI: Kernel 6.x (PREEMPT_VOLUNTARY)
    TS->>CT: 设置 TIF_NEED_RESCHED
    CT->>CT: 继续执行...
    CT->>CP: 运行到检查点
    CP->>CP: 检查 TIF_NEED_RESCHED
    CP-->>TS: 立即让出CPU (快速响应)
    
    Note over TS,TI: Kernel 7.0 (PREEMPT_LAZY)
    TS->>CT: 设置 TIF_NEED_RESCHED_LAZY
    CT->>CT: 继续执行...
    CT->>CP: 运行到检查点
    CP->>CP: 忽略 LAZY 标志
    CT->>CT: 继续执行...
    CT->>TI: 时钟中断到达
    TI->>TI: 升级 LAZY → NEED_RESCHED
    TI-->>TS: 触发抢占 (延迟响应)

简单来说，内核将抢占决策权从”代码中的分散检查点”收拢到了”调度器的时钟中断”中。这简化了内核，但也意味着一个任务在被抢占前，可能会运行更长时间。

三、PostgreSQL 的自旋锁机制：一场对低延迟的极致追求

那么，为什么内核的这个改动会让PostgreSQL”崩溃”呢？答案藏在PostgreSQL为了极致性能而设计的自旋锁（Spinlock） 机制中。

自旋，而不是睡眠

在PostgreSQL的源代码src/backend/storage/lmgr/s_lock.c中，我们可以看到其自旋锁的实现逻辑⁷。当一个进程尝试获取一个已被其他进程持有的自旋锁时，它不会立即进入睡眠状态（这会导致上下文切换，开销巨大），而是会执行一个紧凑的循环，反复检查锁是否已被释放。这个过程被称为自旋（spinning）。

PostgreSQL的代码注释清楚地说明了这一点：

/*
 * When waiting for a contended spinlock we loop tightly for awhile, then
 * delay using pg_usleep() and try again.  Preferably, "awhile" should be a
 * small multiple of the maximum time we expect a spinlock to be held.  100
 * iterations seems about right as an initial guess.  However, on a
 * uniprocessor the loop is a waste of cycles, while in a multi-CPU scenario
 * it's usually better to spin a bit longer than to call the kernel, so we try
 * to adapt the spin loop count depending on whether we seem to be in a
 * uniprocessor or multiprocessor.
 */

实际的自旋锁实现：

int
s_lock(volatile slock_t *lock, const char *file, int line, const char *func)
{
	SpinDelayStatus delayStatus;

	init_spin_delay(&delayStatus, file, line, func);

	while (TAS_SPIN(lock))
	{
		perform_spin_delay(&delayStatus);
	}

	finish_spin_delay(&delayStatus);

	return delayStatus.delays;
}

PostgreSQL的设计哲学是：自旋锁保护的临界区代码应该极其短小，通常只是修改几个指针或标志位。因此，持有锁的时间预期只有几十个CPU指令周期。在这种情况下，“自旋等待”几乎总是比”睡眠唤醒”更快。

当”被误解”的自旋锁遭遇”更懒”的内核

问题在于，PostgreSQL的自旋锁机制对内核的抢占行为有一个强烈的隐含假设：

“我已经把临界区做得非常短了。因此，当我持有自旋锁时，请千万不要抢占我。让我赶紧执行完，释放锁，比让其他CPU上的几十个线程一起自旋空转要好得多。”

在旧的PREEMPT_VOLUNTARY模式下，内核”尊重”了这个假设。虽然理论上任何地方都可能被抢占，但实际情况是，由于临界区极短，在它内部触发抢占的概率微乎其微。

但在Kernel 7.0的PREEMPT_LAZY模式下，情况发生了根本性的变化。虽然临界区很短，但现在，持锁进程在释放锁之前，更有可能”撞上”时钟中断。

让我们一步步推演这个灾难场景：

1. CPU 0上的进程A获得自旋锁L，开始执行临界区代码。
2. 此时，由于某些原因（例如时间片即将用完，或有其他任务被唤醒），调度器为CPU 0设置了TIF_NEED_RESCHED_LAZY标志。
3. 进程A继续执行，它并不知道自己被标记了。它快速执行着临界区代码，眼看就要完成了。
4. 然而，时钟中断发生了。Kernel 7.0的中断处理程序检查到惰性标志，并将其升级为紧急抢占标志。
5. 内核执行抢占：进程A的上下文被保存，它被”踢出”CPU。而它手上还死死握着那把锁L。
6. 现在，其他CPU（如CPU 1, CPU 2, …）上的进程B、C、D想要获取锁L。它们执行TAS操作，发现锁被占用，于是开始自旋。
7. 这些进程在用户态疯狂地自旋、自旋、自旋……消耗着宝贵的CPU周期，却什么有用的工作都没做。
8. 进程A虽然被抢占了，但由于它持有锁，且可能优先级不高，调度器迟迟没有让它重新运行。
9. 最终，经过漫长的等待（对CPU而言），进程A被重新调度，释放了锁。但此时，整个系统的CPU时间已经被无意义的自旋消耗殆尽。

下图展示了这个灾难性的时序：

sequenceDiagram
    participant CPU0 as CPU 0 (进程A)
    participant Lock as 自旋锁L
    participant Sched as 调度器
    participant CPU1 as CPU 1 (进程B)
    participant CPU2 as CPU 2 (进程C)
    
    CPU0->>Lock: 获取锁L
    activate Lock
    CPU0->>CPU0: 执行临界区代码
    
    Note over Sched: 设置 TIF_NEED_RESCHED_LAZY
    Sched-->>CPU0: (标记，但不立即抢占)
    
    CPU0->>CPU0: 继续执行临界区...
    
    Note over CPU0: 时钟中断到达！
    Sched->>CPU0: 升级标志，强制抢占
    Note right of CPU0: 被换出 (仍持有锁L!)
    
    Note over CPU1,CPU2: 其他CPU上的进程尝试获取锁
    
    CPU1->>Lock: TAS_SPIN(lock)
    Lock-->>CPU1: 失败 (锁被占用)
    CPU1->>CPU1: 自旋等待...
    CPU1->>CPU1: 自旋等待...
    
    CPU2->>Lock: TAS_SPIN(lock)
    Lock-->>CPU2: 失败 (锁被占用)
    CPU2->>CPU2: 自旋等待...
    CPU2->>CPU2: 自旋等待...
    
    Note over CPU1,CPU2: CPU空转，浪费算力！
    
    CPU1->>CPU1: 继续自旋...
    CPU2->>CPU2: 继续自旋...
    
    Note over Sched,CPU0: 经过漫长等待...
    Sched->>CPU0: 重新调度进程A
    CPU0->>CPU0: 完成临界区
    CPU0->>Lock: 释放锁L
    deactivate Lock
    
    CPU1->>Lock: TAS_SPIN(lock)
    Lock-->>CPU1: 成功！
    activate Lock
    Note over CPU1,CPU2: 终于可以继续工作了

四、修复方案：内核的设计立场与RSEQ时间片扩展

面对PostgreSQL的性能问题，调度器维护者Peter Zijlstra在commit 476e8583ca16中坚定地在x86架构上启用了PREEMPT_LAZY⁸，提交信息非常简洁：

sched, x86: Enable Lazy preemption

Add the TIF bit and select the Kconfig symbol to make it go.

这一决定背后的设计理念可以从commit 7dadeaa6e851中看出²：引入PREEMPT_LAZY的核心目标是简化内核代码，最终移除所有cond_resched()调用。这是一个正确的技术方向，体现了内核社区的长期愿景：

1. 简化内核：消除内核代码中数百个启发式的cond_resched()检查点
2. 统一调度：将抢占决策集中到调度器，而非分散在代码各处
3. 明确责任：如果用户空间程序依赖特定的抢占行为来保证性能，应该通过显式的内核接口来声明需求，而非依赖隐式假设

官方解决方案：让PostgreSQL使用RSEQ时间片扩展

Peter Zijlstra和Thomas Gleixner给出的解决方案是：让PostgreSQL使用Kernel 7.0中新增的RSEQ（Restartable Sequences）时间片扩展功能⁹。

什么是RSEQ？ RSEQ是一种允许用户空间程序与内核安全地协作，执行一系列原子操作的机制。

时间片扩展是什么？ 这是Thomas Gleixner在2025年12月提交的一系列补丁引入的新特性。在commit d7a5da7a0f7f的用户空间API文档中，明确说明了其目的¹⁰：

This allows a thread to request a time slice extension when it enters a critical section to avoid contention on a resource when the thread is scheduled out inside of the critical section.

这正是为了解决像PostgreSQL这样的应用在持锁期间被抢占导致的性能问题而设计的！

Linux内核在include/uapi/linux/rseq.h中定义了相关接口¹¹：

/**
 * rseq_slice_ctrl - Time slice extension control structure
 * ...
 */
struct rseq_slice_ctrl {
	union {
		__u32		all;
		struct {
			__u8	request;
			__u8	granted;
			__u16	__reserved;
		};
	};
};

struct rseq {
	// ...
	struct rseq_slice_ctrl slice_ctrl;
	// ...
};

其效果是：当该线程持有关键锁（即处于RSEQ临界区）时，内核调度器将暂时”无视”针对它的惰性抢占标志，不会在时钟中断时强行抢占它。这相当于PostgreSQL向内核宣告：”给我几十微秒，我马上就完事，别打断我。”

这完美地解决了我们之前分析的”持锁被抢”的困境。PostgreSQL可以获得它梦寐以求的”短时不可抢占”保证，同时内核也可以继续朝着更简洁、更统一的调度架构演进。

PostgreSQL社区需要在其代码中集成RSEQ时间片扩展的支持。这需要修改PostgreSQL锁管理器（s_lock.c）的实现，在获取自旋锁前请求时间片扩展，释放锁后清除请求，从而避免在持锁期间被抢占。

如何使用RSEQ时间片扩展

根据内核文档¹⁰，应用程序需要按以下步骤启用这个功能：

1. 注册RSEQ：通过rseq()系统调用注册一个用户空间内存区域
2. 启用时间片扩展：通过prctl()启用该功能：

prctl(PR_RSEQ_SLICE_EXTENSION, PR_RSEQ_SLICE_EXTENSION_SET,
      PR_RSEQ_SLICE_EXT_ENABLE, 0, 0);

1. 请求扩展：在进入临界区前，在rseq->slice_ctrl.request字段设置请求位
2. 检查授权：内核会在rseq->slice_ctrl.granted字段返回是否授权

下图展示了RSEQ时间片扩展的完整工作流程：

sequenceDiagram
    participant App as 用户态应用(PostgreSQL)
    participant RSEQ as RSEQ结构(共享内存)
    participant Kernel as 内核调度器
    participant Timer as 时钟中断
    
    Note over App,Kernel: 初始化阶段
    App->>Kernel: rseq() 系统调用
    Kernel-->>RSEQ: 分配共享内存区域
    App->>Kernel: prctl(PR_RSEQ_SLICE_EXTENSION_SET)
    Kernel-->>App: 启用成功
    
    Note over App,Timer: 运行时：进入临界区
    App->>RSEQ: 设置 slice_ctrl.request = 1
    App->>App: 获取自旋锁
    App->>App: 执行临界区代码...
    
    Note over Kernel,Timer: 调度压力出现
    Kernel->>Kernel: 设置 TIF_NEED_RESCHED_LAZY
    Timer->>Kernel: 时钟中断到达
    
    Kernel->>RSEQ: 检查 slice_ctrl.request
    alt 请求有效且无其他待处理工作
        Kernel->>RSEQ: 设置 slice_ctrl.granted = 1
        Kernel->>Kernel: 忽略抢占，允许继续运行
        Note over Kernel: 授予时间片扩展
    else 有待处理工作或其他条件不满足
        Kernel->>RSEQ: 拒绝请求 (granted = 0)
        Kernel->>App: 执行抢占
    end
    
    Note over App,Timer: 完成临界区
    App->>App: 释放自旋锁
    App->>RSEQ: 清除 slice_ctrl.request
    RSEQ-->>Kernel: 下次时钟中断时清除 granted

这个机制的核心实现在commit dfb630f548a7中，由Thomas Gleixner详细说明了授权决策过程¹²：只有在从中断返回用户态、且没有其他待处理工作（如信号）时，才会授予时间片扩展。

五、PostgreSQL与Linux内核的协作历史：NUMA案例

有趣的是，PostgreSQL和Linux内核之间的互动并非总是冲突。一个很好的协作案例发生在2025年，当时PostgreSQL 18引入了新的NUMA内省功能。

在开发过程中，PostgreSQL开发者发现了Linux内核中do_pages_stat()函数的一个长期存在的bug（自2010年起）¹³。这个bug影响所有在64位内核上运行32位用户空间的系统。PostgreSQL开发者Christoph Berg提交了内核修复10d04c26ab2b：

Discovered while working on PostgreSQL 18’s new NUMA introspection code.

For arrays with more than 16 entries, the old code would incorrectly advance the pages pointer by 16 words instead of 16 compat_uptr_t.

同时，PostgreSQL也在自己的代码中实现了规避措施，在commit 7fe2f67c7c9中限制了numa_move_pages请求的大小¹⁴：

This is a long-standing kernel bug (since 2010), affecting pretty much all kernels, so it’ll take time until all systems get a fixed kernel. Luckily, we can work around the issue by chunking the requests the same way do_pages_stat() does, at least on affected systems.

这个案例展示了开源项目之间健康的协作模式：发现问题后，同时修复内核bug并在应用层实现兼容性处理，确保在旧内核上也能正常工作。

六、总结与展望：一次痛苦的蜕变

Kernel 7.0与PostgreSQL的这次”冲突”，并非谁的错，而是计算机系统设计中的一个经典矛盾：通用操作系统的演进 vs. 特定领域应用的极致优化。

• 对Linux而言：PREEMPT_LAZY是一次勇敢的”自我简化”手术。它摒弃了历史包袱，为未来几十年的调度器发展奠定了基础¹⁵。尽管短期内带来了阵痛，但方向是正确的。
• 对PostgreSQL而言：这次事件是一次警醒。它揭示了自己过去一直依赖的”在PREEMPT_VOLUNTARY下不会被抢占”的假设，其实只是一个美丽而脆弱的巧合。拥抱RSEQ等新内核机制，将使其性能模型更加健壮和可移植。

这次性能腰斩事件，本质上是两个高度复杂的系统在”无锁化”和”抢占”的边缘地带，发生的一次深刻的碰撞。它再次证明了一个朴素的真理：在系统软件的世界里，没有银弹。每一个看似微小的”优化”，都可能在其他地方掀起惊涛骇浪。而解决之道，不在于互相指责和回退，而在于更深层次的协作与适配。

最终，一个更简洁、更强大的Linux内核，和一个更健壮、更高效的PostgreSQL，都将从这个痛苦的蜕变中诞生。

References

内核如何决定”现在该换谁运行了”？

引言：操作系统的”心跳”

当你的Linux系统同时运行着数百个进程，内核是如何决定在什么时刻暂停一个任务、让另一个任务运行的？这个看似简单的问题，背后隐藏着操作系统设计中最核心的权衡：公平性 vs. 实时性，吞吐量 vs. 响应延迟。

答案的关键在于一个持续跳动的”心跳”——定时器中断（Timer Interrupt）。它就像一个永不停歇的闹钟，每隔几毫秒就提醒内核：”该检查一下，是不是要换个任务运行了？”

但这只是故事的一部分。本文将深入Linux内核的调度子系统，揭示定时器中断在任务调度中的真实角色，以及它与抢占机制、实时操作系统的微妙关系。

一、定时器中断：调度的驱动力还是可选项？

1.1 传统观点：定时器中断是调度的核心

在经典的操作系统教科书中，任务调度的基本模型是这样的：

sequenceDiagram
    participant HW as 硬件定时器
    participant IRQ as 中断控制器
    participant Kernel as 内核调度器
    participant Task as 当前任务
    
    Note over HW: 每隔固定时间(如1ms)
    HW->>IRQ: 产生定时器中断
    IRQ->>Kernel: 触发中断处理程序
    Kernel->>Kernel: scheduler_tick()
    Kernel->>Kernel: 检查时间片是否用完
    alt 时间片用完
        Kernel->>Task: 设置 TIF_NEED_RESCHED
        Kernel->>Kernel: 触发任务切换
    else 继续运行
        Kernel->>Task: 返回继续执行
    end

这个模型在Linux早期版本（以及许多教学用的简化内核）中是准确的：

1. 硬件定时器（如x86的PIT或APIC timer）每隔固定时间（称为一个”tick”，通常是1ms或10ms）产生中断
2. 内核的时钟中断处理程序被调用
3. 调度器检查当前任务的时间片（time slice）是否用完
4. 如果用完，设置”需要重新调度”标志，在中断返回时触发任务切换

1.2 现代Linux：Tickless与动态时钟

然而，现代Linux内核（特别是启用了CONFIG_NO_HZ_FULL的系统）引入了”tickless”模式¹，彻底改变了这个模型：

传统模式（HZ=1000）：即使CPU完全空闲，每秒也会产生1000次定时器中断。

Tickless模式：当CPU只运行一个任务且没有定时器到期时，内核会完全停止周期性的时钟中断，只在以下情况下设置定时器：

• 有定时器事件需要处理
• 调度器需要检查任务状态
• RCU需要进行grace period处理

这意味着：定时器中断不是调度的必要条件，而是一种优化手段。

graph LR
    subgraph "传统定时器模式 (CONFIG_HZ_PERIODIC)"
        A[1ms] --> B[中断]
        B --> C[1ms]
        C --> D[中断]
        D --> E[1ms]
        E --> F[中断]
    end
    
    subgraph "Tickless模式 (CONFIG_NO_HZ_FULL)"
        G[运行中...] -.->|仅在需要时| H[中断]
        H -.->|可能很长时间| I[中断]
    end
    
    style B fill:#FF6347
    style D fill:#FF6347
    style F fill:#FF6347
    style H fill:#87CEEB
    style I fill:#87CEEB

1.3 那么，调度到底在哪里发生？

Linux内核中，任务切换（调用schedule()函数）可以在以下几个调度点（scheduling point）发生：

结论：定时器中断不是唯一的调度驱动力，但它是保证公平性和防止任务饿死的关键机制。

二、深入内核代码：定时器中断如何触发调度

2.1 时钟中断的处理路径

在Linux内核中，时钟中断的处理流程如下（以x86-64为例）：

硬件中断 → 中断处理程序 → 调度器检查

关键函数调用链（基于Linux 6.x/7.x）：

// arch/x86/kernel/time.c - 时钟中断入口
void __irq_entry smp_apic_timer_interrupt(struct pt_regs *regs)
{
    entering_irq();
    trace_local_timer_entry(LOCAL_TIMER_VECTOR);
    local_apic_timer_interrupt();  // 处理本地APIC定时器
    trace_local_timer_exit(LOCAL_TIMER_VECTOR);
    exiting_irq();
}

调用链继续：

local_apic_timer_interrupt()
  └─> tick_handle_periodic() 或 hrtimer_interrupt()  // 取决于是否启用高精度定时器
      └─> update_process_times()
          └─> scheduler_tick()  // 调度器的时钟处理函数

2.2 调度器的时钟心跳：scheduler_tick()

这是调度器在每个时钟中断中被调用的核心函数，定义在kernel/sched/core.c中²：

/*
 * This function gets called by the timer code, with HZ frequency.
 * We call it with interrupts disabled.
 */
void scheduler_tick(void)
{
    int cpu = smp_processor_id();
    struct rq *rq = cpu_rq(cpu);
    struct task_struct *curr = rq->curr;
    
    // 更新运行队列时钟
    update_rq_clock(rq);
    
    // 调用当前调度类的 task_tick 方法
    curr->sched_class->task_tick(rq, curr, 0);
    
    // 检查是否需要触发负载均衡
    trigger_load_balance(rq);
    
    // ... 其他统计和处理
}

关键点：

1. 每个CPU独立处理：scheduler_tick()在每个CPU上独立运行
2. 调度类多态：通过task_tick回调，不同调度策略（CFS、RT、DEADLINE）有不同的处理逻辑
3. 不直接切换任务：这个函数只标记是否需要重新调度，真正的切换在中断返回时发生

2.3 CFS调度类的时钟处理

对于普通任务（SCHED_OTHER），调度器使用完全公平调度器（CFS）。在kernel/sched/fair.c中³：

static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued)
{
    struct cfs_rq *cfs_rq;
    struct sched_entity *se = &curr->se;
    
    for_each_sched_entity(se) {
        cfs_rq = cfs_rq_of(se);
        entity_tick(cfs_rq, se, queued);
    }
    // ... NUMA平衡等
}

static void entity_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr, int queued)
{
    // 更新当前任务的虚拟运行时间
    update_curr(cfs_rq);
    
    // 检查是否需要抢占
    if (cfs_rq->nr_running > 1)
        check_preempt_tick(cfs_rq, curr);
}

虚拟运行时间（vruntime） 是CFS的核心概念：

• 每个任务都有一个vruntime，表示它已经”使用”了多少CPU时间（按优先级加权）
• 调度器总是选择vruntime最小的任务运行
• check_preempt_tick()检查当前任务的vruntime是否明显大于队列中其他任务，如果是，则设置TIF_NEED_RESCHED

三、抢占机制：何时真正切换任务？

3.1 抢占标志位：TIF_NEED_RESCHED

设置这个标志只是”建议”内核应该切换任务，但何时真正切换取决于抢占模型：

flowchart TD
    A[scheduler_tick 检测到需要切换] --> B[设置 TIF_NEED_RESCHED]
    B --> C{当前在哪里?}
    
    C -->|用户态| D[立即抢占<br/>在中断返回时]
    C -->|内核态| E{抢占模型?}
    
    E -->|PREEMPT_NONE| F[等待系统调用返回<br/>或显式调度点]
    E -->|PREEMPT_VOLUNTARY| G[等待 cond_resched<br/>检查点]
    E -->|PREEMPT_FULL| H[几乎立即抢占<br/>除非持有自旋锁]
    
    style D fill:#90EE90
    style F fill:#FFD700
    style G fill:#FFB6C1
    style H fill:#FF6347

3.2 中断返回路径：实际的切换点

在x86-64架构上，中断返回时的处理（arch/x86/entry/entry_64.S）⁴：

ENTRY(interrupt_return)
    // ... 保存寄存器等
    
    testl $_TIF_NEED_RESCHED, %edi  // 检查是否需要重新调度
    jz restore_regs_and_return       // 如果不需要,直接返回
    
    // 需要调度
    call schedule                     // 调用调度器
    
restore_regs_and_return:
    // ... 恢复寄存器并返回用户态
    iretq

关键点：

• 如果返回用户态，总是会检查并响应TIF_NEED_RESCHED
• 如果返回内核态，取决于配置的抢占模型

四、RTOS vs. 通用Linux：调度哲学的根本差异

4.1 实时操作系统的调度特点

你的草稿中提到了一个关键区别：RTOS的核心不是时间片轮转，而是基于优先级的抢占⁵。

4.2 PREEMPT_RT：将Linux变成RTOS

Linux的PREEMPT_RT补丁⁶通过以下改造，将通用内核变成硬实时系统：

关键技术1：中断线程化

sequenceDiagram
    participant HW as 硬件中断
    participant Handler as 中断处理程序(顶半部)
    participant Thread as 内核中断线程
    participant Sched as 实时调度器
    participant RT as 高优先级RT任务
    
    Note over HW,RT: 标准Linux模式
    HW->>Handler: 中断到来
    activate Handler
    Handler->>Handler: 长时间处理（关闭抢占）
    deactivate Handler
    Note right of Handler: RT任务必须等待
    
    Note over HW,RT: PREEMPT_RT模式
    HW->>Handler: 中断到来
    Handler->>Thread: 唤醒中断线程（极快）
    Thread->>Sched: 进入就绪队列
    Sched->>Sched: 比较优先级
    alt RT任务优先级更高
        Sched->>RT: 立即运行RT任务
    else 中断线程优先级更高
        Sched->>Thread: 运行中断处理
    end

关键技术2：自旋锁变互斥锁

标准Linux中的spinlock在PREEMPT_RT下被替换为rt_mutex（支持优先级继承），避免了高优先级任务在自旋锁上空转的问题。

五、Lazy抢占：Kernel 7.0的新权衡

你的另一篇文章分析的PREEMPT_LAZY⁷正是这个权衡的最新演化：

传统PREEMPT_VOLUNTARY：

// 内核代码中散布的检查点
if (need_resched())  // 检查 TIF_NEED_RESCHED
    schedule();       // 立即让出CPU

新的PREEMPT_LAZY：

// 设置惰性标志
set_tsk_need_resched_lazy(current);

// cond_resched() 不再检查惰性标志
// 只在时钟中断时升级为紧急标志
if (tick_happened && test_lazy_flag())
    set_tsk_need_resched(current);  // 升级为紧急抢占

设计哲学转变：

• 旧模式：通过代码中的启发式检查点实现”礼貌让出”
• 新模式：将抢占决策集中到调度器的时钟中断中，简化内核但增加了抢占延迟

这个改变导致PostgreSQL性能下降的原因，正是因为它破坏了数据库自旋锁对”临界区内不会被抢占”的隐含假设。

六、总结：调度是一门平衡的艺术

回到最初的问题：Linux内核是否核心依赖定时器中断来进行任务调度？

答案是分层的：

1. 理论上：不依赖。系统调用返回、主动让出、I/O阻塞等都可以触发调度。
2. 实践上：依赖。定时器中断是保证公平性、防止任务饿死、更新调度统计的关键机制。
3. 现代内核：可选。Tickless模式下，单任务运行时可以完全没有周期性中断。
4. 实时系统：弱依赖。RTOS更依赖事件驱动的抢占，时钟中断仅用于时间片轮转。

关键技术实现：

• scheduler_tick()：每个时钟中断调用，更新vruntime，检查是否需要抢占
• TIF_NEED_RESCHED标志：建议切换的信号，但何时响应取决于抢占模型
• 中断返回路径：实际任务切换的执行点
• 抢占模型：决定了内核态代码的可中断性

设计权衡：

• 频繁的时钟中断 → 更好的公平性和响应，但更高的开销
• Tickless → 省电和减少干扰，但需要更复杂的调度逻辑
• 全抢占 → 低延迟，但吞吐量可能下降
• 惰性抢占 → 简化内核，但需要应用层适配（如使用RSEQ）

这些权衡没有”完美答案”，只有针对不同场景的”合适选择”。这也是为什么从通用服务器到硬实时系统，Linux提供了如此丰富的调度配置选项。

References

全文分三部分：

• IDT 与 SYSCALL 的机制差异与历史脉络
• x86-64 Linux 上从 syscall 指令到内核服务的执行路径（对照 SDM 与 arch/x86）
• 经 IDT 的入核与 SYSCALL 入核在开销与实现上的对比

硬件叙述以 Intel Software Developer’s Manual（Volume 3A 等）为准，软件以 Linux 主线 arch/x86 为准；引用标号见文末 References。

主题一：IDT 与 SYSCALL 的区别与演化

谁在决定内核入口

• 异常、硬件中断、INT n：CPU 用 IDT（Interrupt Descriptor Table） 按 向量号 取门描述符，再按架构规则完成特权级与栈等处理；OS 负责 填表 并用 LIDT 之类加载 IDTR。该路径与一组 MSR 配合编程的 SYSCALL 入核是两套并存机制¹²。
• SYSCALL（64 位长模式下的系统调用主路径之一）：CPU 根据 IA32_STAR、IA32_LSTAR、IA32_FMASK 等 MSR 切到 ring 0 并跳转到 IA32_LSTAR 指向的 RIP，不查 IDT³⁴。

二者都是架构规定的入口协议，但针对的事件类别不同：前者服务 异步/异常类事件 的统一交付，后者服务 用户态主动发起的系统调用 的专用快速通道。

64 位模式下的 IDT 索引

在 64-bit / IA-32e 下，门描述符为 16 字节；向量 k 对应表项在 IDT 中的字节偏移为 k × 16（与 legacy 模式下 8 字节项不同）¹。

手册在 64-bit mode IDT gate 处写道⁵：

In 64-bit mode, the IDT index is formed by scaling the interrupt vector by 16. The first eight bytes (bytes 7:0) of a 64-bit mode interrupt gate are similar but not identical to legacy 32-bit interrupt gates. The type field (bits 11:8 in bytes 7:4) is described in Table 3-2. The Interrupt Stack Table (IST) field (bits 4:0 in bytes 7:4) is used by the stack switching mechanisms described in Section 6.14.5, “Interrupt Stack Table.” Bytes 11:8 hold the upper 32 bits of the target RIP (interrupt segment offset) in canonical form.

对照表

与「系统调用号 → 内核函数」的关系

抽象上都可说成 编号映射到处理逻辑：IDT 用 中断向量，系统调用用 RAX 中的调用号。
差别在于：IDT 的查表与跳转是 CPU 事件交付的一部分；而 RAX → __x64_sys_* 属于 内核在进入 do_syscall_64 之后的纯软件分发，处理器并不解析“系统调用号”的语义。

三条不同的「表 / 入口 / 快车道」

将机制分为以下三层（可与 上文「对照表」、下文「机制层对比」 对照阅读）：

• IDT（及经其投递的中断/异常/INT n） 由 CPU 规定、面向全体异步与异常事件的 通用交付协议：功能全、约束多，不以“最短一次用户主动系统调用”为唯一优化目标¹²。

• 系统调用分发（软件） Linux 仍保留 sys_call_table[]，方便 trace 等子系统解析符号地址；64 位主路径上则由 x64_sys_call() 的 switch (nr) 落到 __x64_sys_*。无论数组还是 switch，都属于 syscall 已经进核之后 的普通控制流，不是 CPU 替代的 IDT 查表⁶。

• 系统调用硬件快车道（SYSCALL + 若干 MSR） 入口 RIP 与 CS/SS/RFLAGS 掩码由 STAR/LSTAR/FMASK（及 EFER.SCE） 预编程；这是在 不进 IDT 的前提下完成的 ring 3 → ring 0 专用序列³⁵。__x64_sys_* 分发在这一硬件入核序列完成之后，才由 do_syscall_64 / x64_sys_call 等以 普通内核控制流执行⁶。

一条简化的演化脉络（x86 / Linux 相关）

• 80386 及保护模式：IDT 与 INT n 成为统一的异常/中断/软中断交付入口；内核通过设置向量 n 的门，把控制流交给对应处理例程。
• 32 位 Linux：用户态系统调用长期使用 int 0x80，即 CPU 查 IDT 向量 0x80 进入内核（仍属 IDT 路径）⁷。
• 约 Pentium II / Pro 一代：Intel 引入 SYSENTER/SYSEXIT，配合 MSR 提供另一条 不经 IDT 门描述符的 快速进核通道（Linux 在 32 位兼容路径等场景仍会碰到与 SYSENTER/SYSCALL 相关的入口约定）⁸。
• x86-64（AMD64 / Intel 64）：架构在 长模式下提供 SYSCALL/SYSRET（由 IA32_EFER.SCE 等控制使能，细节以 SDM 为准）。64 位 Linux 用户态通常通过 glibc 等内联 syscall，内核入口落在 entry_SYSCALL_64³⁹。
• 并存：今日 64 位内核仍可能为 32 位进程 保留 int 0x80 / SYSENTER / 兼容入口（向量与实现见内核头文件与 entry_64_compat 等）；本文明细以 64 位 syscall 主线为主。

主题二：x86-64 Linux 上 syscall 从 CPU 到内核的完整机制

三层结构（总览）

• CPU（SDM）：用户态约定 RAX=调用号、参数寄存器后执行 syscall。硬件将 RIP → RCX、RFLAGS → R11，按 MSR 加载 CS/SS/RIP，并令 RFLAGS <- RFLAGS & ~IA32_FMASK；不保存 RSP、不向栈压帧。
• 内核入口 entry_SYSCALL_64（arch/x86/entry/entry_64.S）：swapgs、切换到 per-CPU 内核栈，在栈上构造 struct pt_regs，再 call do_syscall_64。
• 分发与返回：do_syscall_64 → x64_sys_call 的 switch (nr) → 各 __x64_sys_*。返回时若满足契约则 SYSRET，否则 IRET。

对比 IDT 路径：IDT 处理「向量 → 硬件按门交付」；syscall 处理「寄存器约定 + MSR 指定 RIP → 软件补全栈帧再交付」。

SYSCALL 与 MSR：多寄存器协同，而非单一 LSTAR

MSR（Model Specific Register） 指通过 RDMSR/WRMSR 访问的 按编号独立编址 的一类寄存器；体系结构里与 SYSCALL 相关的常量名 IA32_STAR、IA32_LSTAR、IA32_FMASK 等各自对应不同 MSR 地址与语义。长模式下执行 SYSCALL 时，处理器按 IA32_EFER.SCE 判定该机制是否可用，再从 STAR/LSTAR/FMASK 读出 CS/SS、目标 RIP 与 RFLAGS 掩码³⁵。

SDM 在 STAR/LSTAR/FMASK 布局处写明⁵：

See Figure 5-14 for the layout of IA32_STAR, IA32_LSTAR and IA32_FMASK.

并在同一节给出 RIP 取自 IA32_LSTAR、RFLAGS 与 IA32_FMASK 的组合关系（正文 「CPU 侧（与 Vol.3A §5.8.8 等一致）」 一节另有逐句引文）。

Linux 在 64 位内核引导路径中与上述分工对齐：syscall_init() 写 MSR_STAR（用户/内核段选择子约定），再调用 idt_syscall_init() 写 MSR_LSTAR（entry_SYSCALL_64）与 MSR_SYSCALL_MASK（对应 IA32_FMASK）¹⁰：

void syscall_init(void)
{
	/* The default user and kernel segments */
	wrmsr(MSR_STAR, 0, (__USER32_CS << 16) | __KERNEL_CS);

	if (!cpu_feature_enabled(X86_FEATURE_FRED))
		idt_syscall_init();
}

static inline void idt_syscall_init(void)
{
	wrmsrq(MSR_LSTAR, (unsigned long)entry_SYSCALL_64);
	/* ia32_enabled() / SYSENTER_* / MSR_CSTAR 分支：见 common.c 全文 */
	wrmsrq(MSR_SYSCALL_MASK,
	       X86_EFLAGS_CF|X86_EFLAGS_PF|X86_EFLAGS_AF|
	       X86_EFLAGS_ZF|X86_EFLAGS_SF|X86_EFLAGS_TF|
	       X86_EFLAGS_IF|X86_EFLAGS_DF|X86_EFLAGS_OF|
	       X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_RF|
	       X86_EFLAGS_AC|X86_EFLAGS_ID);
}

内核里 MSR_SYSCALL_MASK 与手册 IA32_FMASK 对应同一类编程接口；idt_syscall_init() 在 MSR_LSTAR 与兼容路径 MSRs 之间的分支仍以 arch/x86/kernel/cpu/common.c 为准，「内核源码摘录（与上表对应）」 一节给出与当前主线一致的更长摘录。

从机制上概括：IA32_LSTAR 只给出 ring-0 入口 RIP；IA32_STAR 给出 SYSCALL/SYSRET 使用的 CS/SS 选择子场；IA32_FMASK 规定 RFLAGS 在进入时被清除的位；IA32_EFER.SCE 使能整条 SYSCALL/SYSRET 路径³⁵。三颗 MSR 与总开关共同构成 SDM Figure 5-14 所描述的配置平面，操作系统需一并初始化，而不是仅写 LSTAR 一项。

长模式专用：SYSCALL 与 SYSRET —— 三颗 MSR 如何协同工作

核心概念：三个 MSR 各司其职

在 x86-64 长模式下，syscall 和 sysret 指令依赖三个 MSR（模型特定寄存器）来完成用户态到内核态、再回到用户态的完整流程。可以这样理解：

重要说明：本文只讨论 IA-32e 长模式下带 REX.W 的 syscall/sysret 指令，不涉及 IA32_CSTAR 和 SYSENTER/SYSEXIT 等其他机制。

流程图：一条系统调用的完整旅程

下面这个流程图展示了从用户态执行 syscall 到内核处理再到返回用户态的完整过程。每个框里都注明了“此时谁在读/写哪个 MSR”。

sequenceDiagram
    participant OS as 操作系统(启动时)
    participant User as 用户态程序
    participant CPU as CPU硬件
    participant Kernel as 内核态代码

    Note over OS: 操作系统启动时，预先配置 MSR
    OS->>CPU: IA32_EFER.SCE = 1 (开启 syscall 支持)
    OS->>CPU: IA32_STAR = 入核/出核的 CS/SS 选择子
    OS->>CPU: IA32_LSTAR = 内核入口地址
    OS->>CPU: IA32_FMASK = RFLAGS 清零掩码

    Note over User: 用户态准备系统调用
    User->>User: RAX = 系统调用号，参数存入 RDI/RSI/RDX/R10/R8/R9
    User->>User: RSP 指向用户栈

    User->>CPU: 执行 syscall 指令

    Note over CPU: syscall 指令的硬件自动行为
    CPU->>CPU: RCX = 用户态下一条指令的 RIP
    CPU->>CPU: R11 = 用户态完整 RFLAGS
    CPU->>CPU: RIP = IA32_LSTAR (读 MSR)
    CPU->>CPU: CS/SS = IA32_STAR 入核位域
    CPU->>CPU: RFLAGS = RFLAGS & (~IA32_FMASK) (按 FMASK 清零)
    
    Note over CPU: 特权级从 Ring 3 切换到 Ring 0
    CPU->>Kernel: 跳转到 LSTAR 指向的内核入口

    Note over Kernel: 内核处理系统调用
    Kernel->>Kernel: swapgs (切换到内核 GS)
    Kernel->>Kernel: 手动切换 RSP 到内核栈
    Kernel->>Kernel: 保存完整寄存器到内核栈 (形成 pt_regs)
    Kernel->>Kernel: 根据 RAX 查 sys_call_table 分发
    Kernel->>Kernel: 执行具体内核函数，返回值写入 RAX
    Kernel->>Kernel: 恢复寄存器，准备返回

    Kernel->>CPU: 执行 sysretq 指令

    Note over CPU: sysret 指令的硬件自动行为
    CPU->>CPU: CS/SS = IA32_STAR 出核位域
    CPU->>CPU: RIP = RCX (恢复用户态返回地址)
    CPU->>CPU: RFLAGS = R11 (恢复用户态标志位)

    Note over CPU: 特权级从 Ring 0 切换回 Ring 3
    CPU->>User: 跳转到用户态返回地址

    Note over User: 继续执行，RAX 中为系统调用返回值

关键要点（避免踩坑）

syscall 不会自动切换 RSP

• 用户栈指针（RSP）不会被 syscall 指令改变。
• 内核必须在入口代码中手动切换到内核栈（通常用 swapgs + 写 rsp）。
• 这意味着：RSP 的保存和恢复是软件的责任，硬件不管。

sysret 的「契约」

• sysret 指令假设：
  • RCX 中存放着用户态的返回地址（由 syscall 自动保存）。
  • R11 中存放着用户态的 RFLAGS（由 syscall 自动保存）。
• 如果内核代码不小心破坏了 RCX 或 R11，就不能再用 sysret 返回，必须改用 iret 路径。

返回值约定

• 系统调用的返回值必须放在 RAX 中。
• 这是用户态和内核态的约定，sysret 不会动 RAX。

与 int 0x80 + IDT 路径的对比（可选扩展）

如果你想理解为什么这套机制比 int 0x80 快，可以这样对比：

核心结论：syscall 快，不是因为它“做的事少”，而是因为它“用寄存器代替了内存”，并且“去掉了历史包袱”。

在 syscall/sysret 机制中，最核心的 MSR 寄存器是以下三个：

核心三颗 MSR

辅助 MSR

还有一个前提条件相关的 MSR：

一句话总结

IA32_STAR 管“段”（权限），IA32_LSTAR 管“地址”（去哪），IA32_FMASK 管“标志位”（环境），三颗 MSR 配合 IA32_EFER.SCE 开关，共同决定了 syscall 的完整行为。

端到端序列（示意）

sequenceDiagram
    participant User as 用户态进程
    participant CPU as CPU硬件
    participant Kernel as Linux内核
    User->>User: RAX=nr，RDI/RSI/RDX/R10/R8/R9 为 arg0–arg5
    User->>CPU: 执行 syscall
    CPU->>CPU: RCX←返回点 RIP，R11←RFLAGS
    CPU->>CPU: RIP←IA32_LSTAR；RFLAGS 按 IA32_FMASK 清零若干位
    CPU->>Kernel: 进入 entry_SYSCALL_64
    Kernel->>Kernel: swapgs，切内核栈，推 pt_regs
    Kernel->>Kernel: do_syscall_64，x64_sys_call 按 nr 分发
    Kernel->>Kernel: 写回 RAX 返回值或负 errno
    Kernel->>Kernel: 可 SYSRET 则 SYSRET，否则 IRET
    CPU->>User: 回到用户态，自 RCX 所指指令继续

与上图步骤对应的内核代码（linux/arch/x86）

序列图里最前段由用户态约定（glibc / vDSO 等内联 syscall，见 man syscall(2)⁹）；其后为 CPU 根据 IA32_LSTAR/IA32_FMASK/IA32_STAR 的行为，内核侧在启动时写 MSR（idt_syscall_init() 等，见 「内核源码摘录（与上表对应）」 与 ¹⁰）。自 entry_SYSCALL_64 起 按下述代码块列举，惯例与 /Users/weli/works/bootimage-example/LINUX_X86_64_ENTRY_AND_PT_REGS.md 一致：围栏第一行为 起始行:结束行:arch/…/文件（相对 linux/ 源码树根；本文行号依 /Users/weli/works/linux）。

entry_SYSCALL_64（arch/x86/entry/entry_64.S） — IA32_LSTAR 指向此处：swapgs、装入 cpu_current_top_of_stack、pt_regs 布局压栈、PUSH_AND_CLEAR_REGS、movq %rsp,%rdi / movslq %eax,%rsi、call do_syscall_64。

SYM_CODE_START(entry_SYSCALL_64)
	UNWIND_HINT_ENTRY
	ENDBR

	swapgs
	/* tss.sp2 is scratch space. */
	movq	%rsp, PER_CPU_VAR(cpu_tss_rw + TSS_sp2)
	SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp
	movq	PER_CPU_VAR(cpu_current_top_of_stack), %rsp

SYM_INNER_LABEL(entry_SYSCALL_64_safe_stack, SYM_L_GLOBAL)
	ANNOTATE_NOENDBR

	/* Construct struct pt_regs on stack */
	pushq	$__USER_DS				/* pt_regs->ss */
	pushq	PER_CPU_VAR(cpu_tss_rw + TSS_sp2)	/* pt_regs->sp */
	pushq	%r11					/* pt_regs->flags */
	pushq	$__USER_CS				/* pt_regs->cs */
	pushq	%rcx					/* pt_regs->ip */
SYM_INNER_LABEL(entry_SYSCALL_64_after_hwframe, SYM_L_GLOBAL)
	pushq	%rax					/* pt_regs->orig_ax */

	PUSH_AND_CLEAR_REGS rax=$-ENOSYS

	/* IRQs are off. */
	movq	%rsp, %rdi
	/* Sign extend the lower 32bit as syscall numbers are treated as int */
	movslq	%eax, %rsi

	/* clobbers %rax, make sure it is after saving the syscall nr */
	IBRS_ENTER
	UNTRAIN_RET
	CLEAR_BRANCH_HISTORY

	call	do_syscall_64		/* returns with IRQs disabled */

do_syscall_64（前半）、do_syscall_x64、x64_sys_call（arch/x86/entry/syscall_64.c） — 与上引 112–114 行入参一致；合法系统调用号下 regs->ax 在 do_syscall_x64 → x64_sys_call 链上更新。

__visible noinstr bool do_syscall_64(struct pt_regs *regs, int nr)
{
	add_random_kstack_offset();
	nr = syscall_enter_from_user_mode(regs, nr);

	instrumentation_begin();

	if (!do_syscall_x64(regs, nr) && !do_syscall_x32(regs, nr) && nr != -1) {
		/* Invalid system call, but still a system call. */
		regs->ax = __x64_sys_ni_syscall(regs);
	}

	instrumentation_end();
	syscall_exit_to_user_mode(regs);

static __always_inline bool do_syscall_x64(struct pt_regs *regs, int nr)
{
	/*
	 * Convert negative numbers to very high and thus out of range
	 * numbers for comparisons.
	 */
	unsigned int unr = nr;

	if (likely(unr < NR_syscalls)) {
		unr = array_index_nospec(unr, NR_syscalls);
		regs->ax = x64_sys_call(regs, unr);
		return true;
	}
	return false;
}

#define __SYSCALL(nr, sym) case nr: return __x64_##sym(regs);
long x64_sys_call(const struct pt_regs *regs, unsigned int nr)
{
	switch (nr) {
	#include <asm/syscalls_64.h>
	default: return __x64_sys_ni_syscall(regs);
	}
}

__x64_sys_* 原型、sys_call_table[]、生成 syscalls_64.h — 各 __x64_sys_* 实现分布在 kernel/、fs/ 等；编号表 arch/x86/entry/syscalls/syscall_64.tbl，Kbuild 生成 arch/x86/include/generated/asm/syscalls_64.h（$(out) 见下）。

#define __SYSCALL(nr, sym) extern long __x64_##sym(const struct pt_regs *);
#define __SYSCALL_NORETURN(nr, sym) extern long __noreturn __x64_##sym(const struct pt_regs *);
#include <asm/syscalls_64.h>

#define __SYSCALL(nr, sym) __x64_##sym,
const sys_call_ptr_t sys_call_table[] = {
#include <asm/syscalls_64.h>
};

# SPDX-License-Identifier: GPL-2.0
out := arch/$(SRCARCH)/include/generated/asm
uapi := arch/$(SRCARCH)/include/generated/uapi/asm

syscall32 := $(src)/syscall_32.tbl
syscall64 := $(src)/syscall_64.tbl

$(out)/syscalls_64.h: abis := common,64
$(out)/syscalls_64.h: $(syscall64) $(systbl) FORCE
	$(call if_changed,systbl)

SYSRET 快路径与 IRET 慢路径 — do_syscall_64 末尾 return true 且 entry_SYSCALL_64 中 testb %al,%al 成功则 sysretq；否则 jmp / jz 汇入 swapgs_restore_regs_and_return_to_usermode 后经 iretq。

	/*
	 * Check that the register state is valid for using SYSRET to exit
	 * to userspace.  Otherwise use the slower but fully capable IRET
	 * exit path.
	 */

	/* XEN PV guests always use the IRET path */
	if (cpu_feature_enabled(X86_FEATURE_XENPV))
		return false;

	/* SYSRET requires RCX == RIP and R11 == EFLAGS */
	if (unlikely(regs->cx != regs->ip || regs->r11 != regs->flags))
		return false;

	/* CS and SS must match the values set in MSR_STAR */
	if (unlikely(regs->cs != __USER_CS || regs->ss != __USER_DS))
		return false;

	if (unlikely(regs->ip >= TASK_SIZE_MAX))
		return false;

	if (unlikely(regs->flags & (X86_EFLAGS_RF | X86_EFLAGS_TF)))
		return false;

	/* Use SYSRET to exit to userspace */
	return true;

	/*
	 * Try to use SYSRET instead of IRET if we're returning to
	 * a completely clean 64-bit userspace context.  If we're not,
	 * go to the slow exit path.
	 * In the Xen PV case we must use iret anyway.
	 */

	ALTERNATIVE "testb %al, %al; jz swapgs_restore_regs_and_return_to_usermode", \
		"jmp swapgs_restore_regs_and_return_to_usermode", X86_FEATURE_XENPV

	/*
	 * We win! This label is here just for ease of understanding
	 * perf profiles. Nothing jumps here.
	 */
syscall_return_via_sysret:
	IBRS_EXIT
	POP_REGS pop_rdi=0

	/*
	 * Now all regs are restored except RSP and RDI.
	 * Save old stack pointer and switch to trampoline stack.
	 */
	movq	%rsp, %rdi
	movq	PER_CPU_VAR(cpu_tss_rw + TSS_sp0), %rsp
	UNWIND_HINT_END_OF_STACK

	pushq	RSP-RDI(%rdi)	/* RSP */
	pushq	(%rdi)		/* RDI */

	/*
	 * We are on the trampoline stack.  All regs except RDI are live.
	 * We can do future final exit work right here.
	 */
	STACKLEAK_ERASE_NOCLOBBER

	SWITCH_TO_USER_CR3_STACK scratch_reg=%rdi

	popq	%rdi
	popq	%rsp
SYM_INNER_LABEL(entry_SYSRETQ_unsafe_stack, SYM_L_GLOBAL)
	ANNOTATE_NOENDBR
	swapgs
	CLEAR_CPU_BUFFERS
	sysretq

SYM_CODE_START_LOCAL(common_interrupt_return)
SYM_INNER_LABEL(swapgs_restore_regs_and_return_to_usermode, SYM_L_GLOBAL)
	IBRS_EXIT
#ifdef CONFIG_XEN_PV
	ALTERNATIVE "", "jmp xenpv_restore_regs_and_return_to_usermode", X86_FEATURE_XENPV
#endif
#ifdef CONFIG_MITIGATION_PAGE_TABLE_ISOLATION
	ALTERNATIVE "", "jmp .Lpti_restore_regs_and_return_to_usermode", X86_FEATURE_PTI
#endif

	STACKLEAK_ERASE
	POP_REGS
	add	$8, %rsp	/* orig_ax */
	UNWIND_HINT_IRET_REGS

.Lswapgs_and_iret:
	swapgs
	CLEAR_CPU_BUFFERS
	/* Assert that the IRET frame indicates user mode. */
	testb	$3, 8(%rsp)
	jnz	.Lnative_iret
	ud2

.Lnative_iret:
	UNWIND_HINT_IRET_REGS
	/*
	 * Are we returning to a stack segment from the LDT?  Note: in
	 * 64-bit mode SS:RSP on the exception stack is always valid.
	 */
#ifdef CONFIG_X86_ESPFIX64
	testb	$4, (SS-RIP)(%rsp)
	jnz	native_irq_return_ldt
#endif

SYM_INNER_LABEL(native_irq_return_iret, SYM_L_GLOBAL)
	ANNOTATE_NOENDBR // exc_double_fault
	/*
	 * This may fault.  Non-paranoid faults on return to userspace are
	 * handled by fixup_bad_iret.  These include #SS, #GP, and #NP.
	 * Double-faults due to espfix64 are handled in exc_double_fault.
	 * Other faults here are fatal.
	 */
	iretq

从 entry_SYSCALL_64 经 ALTERNATIVE 失败分支也会落到 swapgs_restore_regs_and_return_to_usermode，最终 iretq（上引 559–580、640–659 行；完整标签关系见 ¹¹）。

本地树路径：/Users/weli/works/linux（与主线 torvalds/linux 同源时行号一致；若你本地的 fork 有差异，以 git blame / 实际文件为准。）

CPU 侧（与 Vol.3A §5.8.8 等一致）

1. RIP（下一条指令）→ RCX；RFLAGS → R11³。
2. RIP 来自 IA32_LSTAR；CS/SS 的选择子与 IA32_STAR 的位域布局按 SDM Figure 5-14³。
3. RFLAGS <- RFLAGS & ~IA32_FMASK。Linux 在 arch/x86/kernel/cpu/common.c 的 idt_syscall_init() 中向 MSR_SYSCALL_MASK 写入含 X86_EFLAGS_IF 等位，使进入内核后 IF 通常被清除³¹⁰。
4. SYSCALL 不改变 RSP；SYSRET 也不恢复 RSP，栈由内核显式管理³⁴。

同一节（§5.8.8）对 SYSCALL/SYSRET 的英文原文可对照如下⁵：

For SYSCALL, the processor saves RFLAGS into R11 and the RIP of the next instruction into RCX; it then gets the privilege-level 0 target code segment, instruction pointer, stack segment, and flags as follows:

Target instruction pointer — Reads a 64-bit address from IA32_LSTAR. (The WRMSR instruction ensures that the value of the IA32_LSTAR MSR is canonical.)
Flags — The processor sets RFLAGS to the logical-AND of its current value with the complement of the value in the IA32_FMASK MSR.

The SYSCALL instruction does not save the stack pointer, and the SYSRET instruction does not restore it. It is likely that the OS system-call handler will change the stack pointer from the user stack to the OS stack. If so, it is the responsibility of software first to save the user stack pointer.

（手册在「gets the … as follows」之后对 Target code segment、Stack segment 等另有逐条说明，此处摘入与 LSTAR/FMASK 及 RSP 最直接相关的句子；完整列举见 ¹ 中 §5.8.8 与 Figure 5-14。）

Linux 侧（源码锚点）

内核源码摘录（与上表对应）

下列片段与主线 Linux 树一致，便于和 SDM 对照阅读¹⁰¹¹⁶。

arch/x86/kernel/cpu/common.c — idt_syscall_init() 中写入 MSR_LSTAR 与 MSR_SYSCALL_MASK：

static inline void idt_syscall_init(void)
{
	wrmsrq(MSR_LSTAR, (unsigned long)entry_SYSCALL_64);
	/* ... IA32_SYSENTER_* and ia32_enabled() branches omitted ... */
	/*
	 * Flags to clear on syscall; clear as much as possible
	 * to minimize user space-kernel interference.
	 */
	wrmsrq(MSR_SYSCALL_MASK,
	       X86_EFLAGS_CF|X86_EFLAGS_PF|X86_EFLAGS_AF|
	       X86_EFLAGS_ZF|X86_EFLAGS_SF|X86_EFLAGS_TF|
	       X86_EFLAGS_IF|X86_EFLAGS_DF|X86_EFLAGS_OF|
	       X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_RF|
	       X86_EFLAGS_AC|X86_EFLAGS_ID);
}

arch/x86/entry/entry_64.S — entry_SYSCALL_64 入口（硬件不压栈后，由这里构造 pt_regs 并调用 do_syscall_64）：

SYM_CODE_START(entry_SYSCALL_64)
	swapgs
	movq	%rsp, PER_CPU_VAR(cpu_tss_rw + TSS_sp2)
	SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp
	movq	PER_CPU_VAR(cpu_current_top_of_stack), %rsp
	/* Construct struct pt_regs on stack */
	pushq	$__USER_DS				/* pt_regs->ss */
	pushq	PER_CPU_VAR(cpu_tss_rw + TSS_sp2)	/* pt_regs->sp */
	pushq	%r11					/* pt_regs->flags */
	pushq	$__USER_CS				/* pt_regs->cs */
	pushq	%rcx					/* pt_regs->ip */
	pushq	%rax					/* pt_regs->orig_ax */
	PUSH_AND_CLEAR_REGS rax=$-ENOSYS
	movq	%rsp, %rdi
	movslq	%eax, %esi
	call	do_syscall_64		/* returns with IRQs disabled */

arch/x86/entry/syscall_64.c — sys_call_table[] 注释与 x64_sys_call() 的 switch 分发：

/*
 * The sys_call_table[] is no longer used for system calls, but
 * kernel/trace/trace_syscalls.c still wants to know the system
 * call address.
 */
#define __SYSCALL(nr, sym) case nr: return __x64_##sym(regs);
long x64_sys_call(const struct pt_regs *regs, unsigned int nr)
{
	switch (nr) {
	#include <asm/syscalls_64.h>
	default: return __x64_sys_ni_syscall(regs);
	}
}

同文件 do_syscall_64() — 前半dispatch、末尾返回值决定 SYSRET 与 IRET（以下与中版内核树连续片段一致，仅删去空白行以便排版）：

/* Returns true to return using SYSRET, or false to use IRET */
__visible noinstr bool do_syscall_64(struct pt_regs *regs, int nr)
{
	add_random_kstack_offset();
	nr = syscall_enter_from_user_mode(regs, nr);
	instrumentation_begin();
	if (!do_syscall_x64(regs, nr) && !do_syscall_x32(regs, nr) && nr != -1) {
		regs->ax = __x64_sys_ni_syscall(regs);
	}
	instrumentation_end();
	syscall_exit_to_user_mode(regs);
	if (cpu_feature_enabled(X86_FEATURE_XENPV))
		return false;
	if (unlikely(regs->cx != regs->ip || regs->r11 != regs->flags))
		return false;
	if (unlikely(regs->cs != __USER_CS || regs->ss != __USER_DS))
		return false;
	if (unlikely(regs->ip >= TASK_SIZE_MAX))
		return false;
	if (unlikely(regs->flags & (X86_EFLAGS_RF | X86_EFLAGS_TF)))
		return false;
	return true;
}

主题三：经 IDT 的路径与 SYSCALL 路径的性能与开销

syscall 相对 int + IDT 更快，主要不是因为“少查一次内存里的表”，而是因为 int 走 IDT 门与异常/中断类交付，含 门与特权相关检查、中断帧布局，返回侧又常配合 IRET；SYSCALL/SYSRET 针对系统调用做了裁剪。内核里的 调用号分发发生在两条路径入核之后，不是整体差距的主因。

路径对比（示意）

graph TD
    subgraph 快路径_syscall
    A[用户态] -->|syscall| B[CPU]
    B -->|读 LSTAR/STAR/FMASK| C[内核入口 entry_SYSCALL_64]
    C -->|do_syscall_64 + x64_sys_call| D[__x64_sys_*]
    end

    subgraph 传统路径_int0x80
    E[用户态] -->|int 0x80| F[CPU]
    F -->|经 IDT 向量门| G[中断门入口]
    G -->|中断类交付与返回| H[内核处理]
    end

graph TD
    subgraph 快路径_syscall
    A1[用户态] -->|syscall| B1[CPU]
    B1 -->|从 MSR 取入口| C1[内核入口]
    C1 -->|软件分发| D1[__x64_sys_* 等]
    end

    subgraph 慢路径_int_idt
    E1[用户态] -->|int 0x80| F1[CPU]
    F1 -->|查 IDT| G1[IDT 门]
    G1 -->|特权与栈检查 + 转入处理程序| H1[内核入口]
    H1 -->|再做软件分发| I1[具体例程]
    end

机制层对比

单次查表与整条路径

硬件对 IDT 的一次访问与 内核对 switch (nr) 的几条指令各自都很快；差别主要来自 整条入核/出核：多保存了哪些状态、是否经过 IDT 门语义、返回是 IRET 全功能还是 SYSRET 窄契约、以及 Linux 在出口是否 回退到 IRET。

入核与出核：int 0x80 与 syscall 的步骤对照

下表沿用在 IDT + IRET 与 SYSCALL + SYSRET（及 Linux 可能回退的 IRET） 之间做对照的常见写法；其中 int 路径的栈帧以 64 位长模式下向内核栈压入的字段为准（SS、RSP、RFLAGS、CS、RIP 及可能的错误码等）¹，与 legacy 保护模式下部分教材中的“多段寄存器”示意图并不完全同形。

同一组维度在 syscall 专题里也可以压缩理解：宏观上都要完成 ring 切换与寄存器约定，微观上 SYSCALL/SYSRET 把可由专用指令“包办”的部分收紧，int/IDT/IRET 为覆盖全体中断/异常类型保留更宽的默认行为。

与上表对应的三个技术要点（64 位长模式）

以下三点承接 上文「入核与出核」对照表，用语与 IA-32e 长模式 下的栈帧布局及当前 Linux arch/x86/entry 实现一致。

• 硬件保存的寄存器现场不同 INT n 经 IDT 时走 通用中断/异常交付：在 64 位长模式下，CPU 向 当前特权级 0 栈 压入 SS、RSP、RFLAGS、CS、RIP 及视向量而定的 错误码 等，与同一条 IRET 恢复约定兼容、并由全体 IDT 向量共享这一框架¹。SYSCALL 不向栈压帧，仅用 RCX、R11 分别保留 RIP、RFLAGS 的返回契约信息；通用寄存器与 RSP 等由 entry_SYSCALL_64 等 软件路径 写入 struct pt_regs³¹¹。

• 是否经过 IDT 与 DPL 检查 INT n 根据 门描述符 做 DPL、门类型 等与 软件中断 相关的一致性检查¹。SYSCALL 不读取 IDT 门：CPL 0 入口 RIP、段与 RFLAGS 掩码由 IA32_LSTAR、IA32_STAR、IA32_FMASK 及 IA32_EFER.SCE 预先约定³⁵；合法性依赖 OS 对这些 MSR 与 GDT 项的初始化以及内核入口实现。

• 返回路径的恢复范围 IRET 从栈上 中断帧 恢复 SS、RSP、RFLAGS、CS、RIP 等，语义覆盖完整¹。SYSRET（长模式下 REX.W）在契约成立时仅从 RCX、R11 恢复 RIP、RFLAGS，用户态 CS/SS 按 IA32_STAR 出核位域装载⁴。Linux 在 do_syscall_64 中若判定 SYSRET 契约不成立或须走通用返回路径，则 改用 IRET⁶。

数量级举例

在常见 x86-64 桌面平台上，对 getpid 类极短系统调用做周期计数，int 0x80 有时可达约 二百周期量级，syscall 多在约 数十至百余周期量级，可差数倍。结果强依赖 CPU、微架构、是否实际走 SYSRET 与测量方法；定量的结论应在目标机上用 perf 等重复测量。

小结

• IDT：通用 事件交付 机制，优先保证覆盖面与一致性，不以最短系统调用为唯一目标。
• 系统调用分发：x64_sys_call 的 switch 为主路径；sys_call_table[] 仍服务 观测/枚举 等需求；二者都在 syscall 已进核之后 执行。
• SYSCALL + MSR：系统调用 专用硬件入口协议；真正缩短的是 经 MSR 的入核与在条件允许时的 SYSRET 返回，不是“少做一次 C 层分发”。
• Linux：即便从 syscall 入核，仍可能在出口选用 IRET，与 SYSRET 契约及历史、安全问题有关⁶。

建议的自修顺序

• SDM：中断/异常与 IDT、SYSCALL/SYSRET。
• Linux：common.c（MSR）→ entry_64.S → syscall_64.c。
• 对照阅读：entry_64.S 与 syscall_64.c，结合文末 References。

References

1. 引言

在单机环境中，Bash 脚本通过管道组合文本处理工具（如 grep、sort、uniq、wc）完成数据处理任务。在分布式环境中，RDD 提供了类似的函数式 API，但将执行扩展到集群，并引入了惰性求值与容错机制。

理解 RDD 的一种有效方式是将其视为「分布式版的 Bash 管道」，其中每个命令对应一个转换操作，管道的末端对应一个触发执行的动作。

2. 核心概念映射

2.1 执行模型对比

2.2 操作类比

3. 示例分析：Web 访问日志处理

3.1 业务场景

分析 Web 服务器日志，统计状态码为 404 的请求中，出现次数最多的前 5 个 URL 路径。

3.2 Bash 脚本实现

# 过滤状态码为404的行，提取URL路径，统计并排序
grep " 404 " access.log | \
awk '{print $7}' | \
sort | \
uniq -c | \
sort -nr | \
head -5

执行特点：

• 每条命令立即执行
• 中间结果通过管道在内存中传递
• 单机顺序处理

3.3 RDD 实现

val logRDD = sc.textFile("hdfs://cluster/logs/access.log")

val top404Urls = logRDD
  .filter(line => line.contains(" 404 "))          // 等价于 grep
  .map(line => line.split(" ")(6))                 // 等价于 awk，提取URL
  .map(url => (url, 1))                            // 准备计数
  .reduceByKey(_ + _)                              // 等价于 uniq -c
  .map(_.swap)                                     // 交换键值以便排序
  .sortByKey(ascending = false)                    // 等价于 sort -nr
  .take(5)                                         // 等价于 head -5

top404Urls.foreach(println)

执行特点：

• 所有转换（filter、map、reduceByKey）构建 DAG，不立即执行
• take(5) 作为动作触发分布式计算
• 数据自动分片，并行处理
• 节点故障时自动基于血缘重算

4. 执行机制深入

4.1 惰性求值（Lazy Evaluation）

Bash 采用渴望求值（Eager Evaluation），每个命令立即执行：

# 立即执行 grep，再执行 wc
grep "ERROR" app.log | wc -l

RDD 采用惰性求值，只有动作调用时才执行：

val errors = logRDD.filter(_.contains("ERROR"))  // 仅记录转换
val count = errors.count()                       // 触发执行

优势：

• 允许执行计划优化（如谓词下推）
• 避免不必要的数据扫描
• 支持中间结果缓存复用

4.2 缓存机制类比

val intermediate = logRDD.filter(_.contains("404"))
intermediate.cache()                         // 类似写入临时文件
val count = intermediate.count()             // 首次计算并缓存
val sample = intermediate.take(10)           // 从缓存直接读取

5. 容错机制

5.1 Bash 的容错

# 简单的重试逻辑
for i in {1..3}; do
    grep "ERROR" app.log > result.txt && break
    sleep 5
done

5.2 RDD 的容错（血缘 Lineage）

RDD 记录每个转换操作的血缘关系。当分区数据丢失时，系统自动从源头或缓存重建：

val rdd1 = sc.textFile("data.txt")      // 源头
val rdd2 = rdd1.filter(_.contains("key")) // 转换1
val rdd3 = rdd2.map(_.split(",")(0))      // 转换2
val result = rdd3.count()                 // 动作

// 若某分区在计算 count 时丢失，Spark 根据血缘从 data.txt 重新计算 rdd1→rdd2→rdd3 的该分区

6. 思维模型总结

7. 结论

RDD 可以视为分布式、容错、惰性求值的 Bash 管道。它将 Bash 脚本中「命令 → 管道 → 重定向」的模型，扩展为「转换 → 血缘 → 动作」的分布式计算模型。对于熟悉单机文本处理的开发者，通过这种类比可以快速理解：

• 转换 = 管道中的命令（如 filter、map）
• 动作 = 触发执行的命令（如 count、collect）
• 缓存 = 临时文件复用
• 血缘 = 自动化的错误重试机制

这种映射不仅有助于降低学习曲线，也为设计高效的分布式数据处理流程提供了清晰的思维框架。

附录：操作对照表

文档版本：1.0
适用场景：RDD 编程入门、技术培训、思维模型转换

记录将现网 Java task_server、proc_server 与共享契约迁到 huiwing workspace（htyts_models + htyts + htyproc）的过程：如何用 Cursor 里的迁移计划驱动迭代、如何复用 AuthCore/htycommons，以及如何用 GitHub Actions、Diesel 迁移、Docker Compose 与 AuthCore 联调测试把回归成本压进流水线。

背景：计划里写什么，代码里落什么

迁移前在 Cursor 里整理了一份结构化计划（rust_迁移_task_ts_proc），核心不是「逐文件翻译 Java」，而是先把契约钉死：

• task_server → 对外仍是 **/api/v1/ts/**：任务 CRUD、one_pending_task / one_zombie_task、分页列表，以及原 Quartz 承载的课程通知（改为 Rust 侧调度 + HTTP 调 htyuc/htykc）。
• proc_server → htyproc：拉取 pending、按 TaskType 分发、与 Ts/Ai/Ngx/Uc/Ws 等下游 HTTP 对齐。
• 共享数据 → htyts_models：与现网 JSON 兼容的 ReqTask、payload、DbTask 行结构；PostgreSQL + Redis（TS_ 前缀等与 Java 一致），并优先复用 AuthCore htycommons 的 HtyResponse、Axum 提取器、JWT 等，而不是在私有仓库里再造一套「长得像」的协议。

计划里同时写清了仓库边界：任务域专有逻辑默认闭环在 huiwing；对 AuthCore 的改动要满足开源仓库的兼容、通用与安全预期——这一条直接影响了「哪些代码进 htyts_models、哪些只借鉴模式」。

改造前后：进程与 crate 边界

flowchart LR
  subgraph before [改造前 Java]
    direction TB
    TS[task_server<br/>JAX-RS /api/v1/ts]
    PR[proc_server<br/>TaskProcessor]
    TC[task_commons<br/>DbTask ReqTask Redis]
    TS --> TC
    PR --> TC
  end

  subgraph after [改造后 Rust / huiwing]
    direction TB
    HTYTS[htyts<br/>Axum /api/v1/ts]
    HPROC[htyproc<br/>拉取与处理器]
    HM[htyts_models<br/>契约与 Diesel]
    HC[htycommons<br/>AuthCore]
    HTYTS --> HM
    HPROC --> HM
    HTYTS --> HC
    HPROC --> HC
  end

  TC -.->|契约对齐<br/>HTTP 路径与 JSON| HM

迁移后的运行时结构（与现网调用关系）

flowchart TB
  subgraph clients [调用方]
    WEB[htymusic / htyadmin]
    NGXL[OpenResty / Lua]
  end

  subgraph htyts_crate [htyts]
    API["/api/v1/ts"]
    KC["/api/v1/ts/kc 课程通知调度"]
  end

  PG[(PostgreSQL<br/>dbtask)]
  RD[(Redis<br/>TS_ payload)]

  subgraph htyproc_crate [htyproc]
    LOOP[拉取 one_pending_task]
    HANDLERS[按 TaskType 处理]
  end

  subgraph downstream [下游 HTTP]
    UC[htyuc]
    WS[htyws]
    KC2[htykc]
    AISVC[ai 服务]
    NGX[ngx / OpenResty]
  end

  WEB --> API
  NGXL --> API
  API --> PG
  API --> RD
  KC --> UC
  KC --> KC2

  LOOP -->|GET pending| API
  HANDLERS --> UC
  HANDLERS --> WS
  HANDLERS --> KC2
  HANDLERS --> AISVC
  HANDLERS --> NGX
  HANDLERS -->|POST update_task| API

实际落到仓库里的变更（2026-03-22 前后）

主线已合入 huiwing 的 main（含 PR #1631 的合并），与本次主题相关的提交大致可以读成三层：

1. feat(rust): task_server / proc_server 迁移
   在工作区引入 htyts_models、htyts、htyproc，把 Java 侧任务 API 与处理器迁到 Rust，并与现有 workspace（Axum、htycommons、依赖版本）对齐。

2. feat(htyts_models): Diesel migrations + schema/DbTaskRow + refactor(htyts): move DB ops into htyts_models
   用 Diesel 管理 dbtask 表结构（migrations/、diesel.toml、schema.rs），把数据库访问集中到 htyts_models（风格上对齐 htyuc_models），htyts 通过重导出与 handler 调用；E2E 侧改为 diesel migration run，去掉维护一份独立 init.sql 的漂移风险。实现细节上顺带处理了与 workspace 里 reqwest 版本相关的 URL 拼装（例如用 url::form_urlencoded 等与现有服务一致）。

3. ci: HTYTS + AuthCore 周更联调与本地 docker-compose

   • GitHub Actions：轻量的 rust-ts.yml 仍在 PR/push 上跑：Postgres + Redis + diesel_cli + 迁移 + cargo test -p htyts --test ts_e2e_http。
   • 重任务：单独 workflow 仅 schedule（例如每周）+ workflow_dispatch，clone AuthCore、双库迁移、构建并启动 htyuc、再跑依赖真实 UC 的集成测试；避免把「起一整条 AuthCore 链」绑在每一次 PR 上。
   • 本地：docker-compose.authcore-e2e.yml + scripts/run-authcore-e2e-docker.sh，用固定宿主机端口起双 Postgres + Redis，脚本里处理 LOGGER_LEVEL、env -u CARGO_TARGET_DIR 构建 htyuc（避免 IDE 注入的 target 目录导致找不到二进制）等踩坑点。

合并顺序上，#1631 把 Diesel/DB 重构与 CI 演进合进主线后，又与已存在的 AuthCore 联调提交并存于历史里；若只看「最终能力」，可以理解为：主线同时具备 Diesel 管理的任务表、轻量 HTTP E2E、以及与 AuthCore UC 的可选联调路径。

数据层：Diesel 迁移与 crate 分工

flowchart LR
  subgraph repo [仓库内]
    MIG[htyts_models/migrations]
    SCH[schema.rs + DbTaskRow]
    OPS[impl 于 models.rs]
    MIG --> SCH
    SCH --> OPS
  end

  subgraph consumers [使用者]
    H[htyts handlers]
    H --> OPS
  end

  subgraph ci [CI / 本地]
    D[diesel migration run]
    D --> MIG
  end

我们怎样用 AI 完成「重写」而不是「胡写」

结合上面那份计划，实际协作方式更接近下面几条，而不是「一句话生成整个仓库」：

1. 计划即边界
   把 Java 包路径、现网路由、Redis 前缀、与 htykc/htyuc 的调用关系写进计划后，后续无论是拆 crate 还是写 handler，都有一个可对照的清单，减少模型自由发挥。

2. 契约优先于行数
   先固定 ReqTask / HtyResponse / 错误码与 Java 行为一致，再补实现；AI 适合批量生成样板与对称的 handler，但字段名、状态机、与 UC 的 JWT 语义需要人眼对照现网或集成测试。

3. 迭代式纠偏
   例如联调 UC 时发现：verify_jwt 在 UC 侧会查 Redis 里是否存有与 token_id 对应的完整 JWT——本地随手 jwt_encode_token 出来的串并不会过校验；最终 E2E 改为走 login_with_password（fixture 用户） 拿「已在 UC Redis 里登记」的 token，这是对真实协议的修正，而不是计划里一开始就能写全的细节。

4. Review 仍然是闸门
   AI 加速的是起草与重构 diff；合并进 main 仍走 PR、CI 绿灯与人工扫一眼安全面（密钥、日志、对外 HTTP）。

人机协作工作流（计划驱动）

flowchart TD
  PL[迁移计划与契约清单<br/>Java 路径 / Redis 前缀 / 路由]
  ISS[拆解为可执行 Issue 与 Prompt]
  AI[AI 起草实现与重构]
  PR[PR 与自动化测试]
  PL --> ISS
  ISS --> AI
  AI --> PR
  PR --> RV{评审与对照现网}
  RV -->|需纠偏| ISS
  RV -->|通过| MAIN[合并 main]

GitHub CI 与基础设施：E2E 分两层做

• 默认 CI（每次 PR）
  Docker services 起 Postgres + Redis，迁移到最新 schema，跑 ts_e2e_http。成本可控、反馈快，适合防止「改 handler 把契约改断」。

• AuthCore 联调（周更 / 手动）
  需要第二套 PG（UC 库）、UC 的 diesel + fixture SQL、以及 release 级 htyuc 进程；测试用例标成 #[ignore]，只在专门 workflow 或本地脚本里加 --ignored 跑。这样不把重依赖强加给每个贡献者，又能在主干上周期性验证「HTYTS + HTYUC + 同一 JWT_KEY」这条真实链路。

• 本地 Docker Compose
  与 CI 同源的思路：compose 只负责基础设施，业务进程（htyuc、Rust 测试）仍在宿主机用 cargo 跑，便于调试日志与 attach；脚本把环境变量、端口、以及 UC 启动条件写死成可重复的一步。

CI 与 E2E：轻量 PR 与重联调分流

flowchart TB
  subgraph every_pr [每次 PR / push — rust-ts.yml]
    E1[GitHub Actions job]
    E2[Service: Postgres + Redis]
    E3[diesel_cli + migration run]
    E4["cargo test ts_e2e_http"]
    E1 --> E2 --> E3 --> E4
  end

  subgraph weekly [周更或手动 — htyts-authcore-weekly.yml]
    W1[checkout huiwing + AuthCore]
    W2[双 Postgres + Redis]
    W3[UC migrate + fixture SQL]
    W4[build htyuc release + 启动]
    W5["cargo test ts_e2e_authcore_http -- --ignored"]
    W1 --> W2 --> W3 --> W4 --> W5
  end

  subgraph docker_local [本地复现]
    D1[docker-compose.authcore-e2e]
    D2[run-authcore-e2e-docker.sh]
    D1 --> D2
  end

  every_pr -.->|快速回归契约| MR[合并信心]
  weekly -.->|真实 UC verify 链路| MR
  docker_local -.->|与 CI 同构调试| MR

联调链：sudo 校验走 HTYUC（概念）

sequenceDiagram
  participant C as 客户端
  participant TS as htyts
  participant R as TS Redis 缓存
  participant UC as htyuc

  C->>TS: create_task + HtySudoerToken
  alt 缓存未命中且 TOKEN_VERIFY=true
    TS->>UC: POST verify_jwt_token
    UC->>UC: JWT 与 UC Redis 一致则 r=true
    UC-->>TS: HtyResponse
    TS->>R: 写入 sudo 缓存
  else 缓存命中
    TS->>R: 读 TS_SUDO_T
  end
  TS-->>C: 201 / 业务响应

小结

这一轮迁移的本质是：用一份明确的迁移计划约束 AI 与人工的分工，用 Diesel + CI 迁移步骤约束 schema 与运行时一致，再用 分层 E2E（轻量每次跑、重联调周期跑 + 本地 compose） 把「像 Java 一样能跑」变成可重复验证的事实。若你也在做「Java 服务 → Rust + 现网契约不变」，最值得提前投资的往往是契约文档与 CI 里的数据库/迁移，其次才是具体某一层的代码行数。

仓库：alchemy-studio/huiwing；开源基础设施：alchemy-studio/AuthCore。文中涉及的 PR、workflow 与脚本以仓库当前 main 为准。

一、概念说明：__stack_chk_guard 是什么

__stack_chk_guard 本质上是 canary（金丝雀）参考值。编译器在函数入口和出口自动插入检查逻辑：

1. 函数入口：把 guard 值保存到当前函数栈帧。
2. 函数返回前：比较栈中的副本和原始 guard。
3. 不一致：调用 __stack_chk_fail()，进程立即终止。

这个机制的安全意义是：攻击者若想覆盖返回地址，通常必须先破坏 canary，而 canary 一旦被改写，函数返回前就会被检测出来。

二、谁在做这件事：编译器与 C 库分工

栈保护不是单一组件完成，而是协同机制：

• 编译器（GCC/Clang）：负责插桩，自动生成“保存 canary / 校验 canary”代码。
• libc（musl/glibc）：负责初始化 guard，并提供失败处理函数 __stack_chk_fail。

所以需要明确：__stack_chk_guard 变量本体属于用户态运行时，不是“内核维护的全局变量”。内核通常只在进程启动时通过 AT_RANDOM 等渠道提供随机熵。

三、具体例子：一个会溢出的登录函数

下面是一个最小示例（故意保留不安全写法）：

#include <stdio.h>
#include <string.h>

void login(const char *password) {
    char buffer[8];
    int is_admin = 0;

    strcpy(buffer, password);  // 无边界检查，存在溢出风险

    if (strcmp(buffer, "secret") == 0) {
        is_admin = 1;
    }

    puts(is_admin ? "welcome admin" : "bad password");
}

3.1 不启用栈保护时

如果输入超过 buffer 容量，溢出会继续覆盖相邻栈数据，严重时可改写返回地址，形成控制流劫持入口。

3.2 启用栈保护后

编译器会在 login 的序言保存 canary，在尾声做比较。如果输入过长导致 canary 被覆盖，返回前触发失败处理，进程中止。典型编译方式：

gcc -O2 -fstack-protector -o demo demo.c

更激进版本：

gcc -O2 -fstack-protector-all -o demo demo.c

典型失败输出（glibc 环境常见）：

*** stack smashing detected ***: terminated
Aborted (core dumped)

3.3 简单场景说明（按输入长度看行为）

这个例子可以直接用三种输入理解：

1. 输入 secret（6 字节）
   buffer[8] 能完整容纳，不发生溢出，canary 不变，函数正常返回。
2. 输入 12345678（8 字节）
   刚好写满缓冲区边界，通常也不会覆盖 canary，函数正常返回。
3. 输入 123456789（9 字节及以上）
   超出缓冲区后继续向后写，极易覆盖 canary；函数尾声比较失败，调用 __stack_chk_fail 终止进程。

对应内存上的直觉是：想碰到返回地址，先要经过 canary 槽位；canary 先变，程序就先终止。

四、代码分析：从汇编模式到运行时路径

不同架构指令细节不同，但总体结构一致。可抽象为：

; 函数入口
load guard -> reg
store reg -> [stack_canary_slot]

; ... 函数主体 ...

; 函数返回前
load [stack_canary_slot] -> reg1
load guard -> reg2
cmp reg1, reg2
jne __stack_chk_fail
ret

这解释了为什么该机制能拦住大量“覆盖返回地址”的经典栈溢出：覆盖路径上必须先穿过 canary 槽位。

五、__stack_chk_guard 何时会变化

正常情况下，guard 在进程启动早期初始化一次，随后应保持稳定。运行中发现 guard 改变，通常意味着以下之一：

• 发生了严重内存破坏（例如任意地址写、全局区越界）。
• 调试或安全研究场景下被人工改写（如 GDB、注入库）。
• 程序自身存在未定义行为导致误写。

因此，“运行时 guard 变化”是高度可疑信号，不应视为正常现象。

六、musl C 代码说明（定义、初始化、线程传播、失败路径）

下面用你分析中对应的 musl 代码路径来说明关键点。

6.1 __stack_chk_guard 定义与 __init_ssp 初始化

src/env/__stack_chk_fail.c（简化）：

uintptr_t __stack_chk_guard;

void __init_ssp(void *entropy)
{
    if (entropy) memcpy(&__stack_chk_guard, entropy, sizeof(uintptr_t));
    else __stack_chk_guard = (uintptr_t)&__stack_chk_guard * 1103515245;

#if UINTPTR_MAX >= 0xffffffffffffffff
    ((char *)&__stack_chk_guard)[1] = 0;
#endif

    __pthread_self()->canary = __stack_chk_guard;
}

这段代码表达了四件事：

1. guard 是用户态全局变量（uintptr_t __stack_chk_guard;）。
2. 优先使用外部熵（entropy，通常来自 AT_RANDOM）。
3. 无熵时使用兜底值（可用但强度较弱）。
4. 初始化后同步到当前线程的 canary 字段，供线程上下文中的检查路径使用。

6.2 进程启动阶段如何把 AT_RANDOM 传给 __init_ssp

src/env/__libc_start_main.c（简化）：

void __init_libc(char **envp, char *pn)
{
    size_t i, *auxv, aux[AUX_CNT] = { 0 };
    ...
    for (i=0; auxv[i]; i+=2)
        if (auxv[i] < AUX_CNT) aux[auxv[i]] = auxv[i+1];
    ...
    __init_tls(aux);
    __init_ssp((void *)aux[AT_RANDOM]);
    ...
}

这里的关键是：在 main 执行前，musl 已完成 guard 初始化。
所以业务代码进入前，SSP 依赖的数据已就绪。

6.3 线程结构与新线程 canary 继承

线程结构中有 canary 字段（src/internal/pthread_impl.h）：

struct pthread {
    ...
    uintptr_t canary;
    ...
};

线程创建时复制父线程 canary（src/thread/pthread_create.c）：

new->canary = self->canary;

这保证了多线程下 canary 数据在运行时结构里是一致可用的。

6.4 校验失败后的处理：__stack_chk_fail

src/env/__stack_chk_fail.c（简化）：

void __stack_chk_fail(void)
{
    a_crash();
}

musl 的失败路径非常短：直接崩溃退出，不尝试恢复。
这是典型 fail-fast 策略，避免在“栈已损坏”状态继续执行复杂逻辑。

6.5 musl 这一套实现的工程特征

• 启动期初始化清晰：__init_libc -> __init_ssp。
• 线程传播路径直接：当前线程写入 + 新线程继承。
• 失败处理最小化：a_crash() 终止，降低攻击面。

七、glibc 对照：同目标，不同工程风格

glibc 与 musl 在核心目标上一致：都通过 canary 检测栈破坏并 fail-fast。差异更多体现在工程层面：

• 平台适配路径更复杂；
• 错误提示通常更显式（常见 stack smashing detected）；
• 失败处理同样尽量克制，避免依赖过多复杂运行时状态。

八、边界与局限：它不是万能防护

__stack_chk_guard 很重要，但能力边界也要明确：

• 主要针对栈上的典型覆盖路径；
• 对堆溢出、信息泄露、UAF、逻辑漏洞不直接提供完整防护；
• 需要和 ASLR、NX、RELRO、FORTIFY_SOURCE 等机制组合使用；
• 也不能替代安全编码（边界检查、避免危险 API、最小权限设计）。

九、实践建议

1. 在构建系统中默认启用 -fstack-protector-strong（或更强策略）。
2. 同时启用 PIE、RELRO、NX 和 FORTIFY_SOURCE。
3. 优先替换高风险 API（如 strcpy, sprintf, gets）。
4. 将 canary 视为“最后一道完整性检查”，而非唯一安全策略。

十、结论

__stack_chk_guard 的价值可以概括为一句话：
它通过“函数级栈完整性校验”把很多本可沉默成功的栈覆盖攻击，转化为可检测、可终止的失败路径。

从机制到实现，无论是 musl 还是 glibc，本质都遵循同一个原则：在控制流可信度下降时，尽快停止执行，避免把漏洞升级为可利用攻击。

用户态栈空间有限（如 ulimit -s 的 8MB），访问栈底之外的地址会触发缺页；内核在缺页处理中决定是扩展栈（分配新页）还是拒绝访问（发 SIGSEGV）。本文从内核视角说明：用户栈在 Linux 里如何表示、缺页时栈如何向下扩展、为何会触顶溢出，以及缺页次数、页缓存与架构（如 ARM64 页大小）对现象的影响。文内引用内核源码路径与片段均对应本地树 linux/（如 /Users/weli/works/linux），便于对照阅读。

一、现象与问题

一个常见现象：用 perf stat -e page-faults 跑一个「不断向栈下增长直到崩溃」的程序，可能只看到几百次缺页就发生 SIGSEGV，而栈已使用数 MB。会自然产生两个问题：

1. 为什么「这么少」的缺页就会栈溢出？
2. 缺页次数在不同运行、不同架构下为何差异很大（例如 x86-64 第二次运行明显减少，ARM64 首次就很少）？

下面用内核机制统一解释，并用 stack-vs-heap-benchmark 中的 stack_overflow_test crash 作为可复现的样例（非论述主体）。

二、用户栈在内核中的表示

用户栈对应一个向下增长的 VMA（struct vm_area_struct），由 VM_GROWSDOWN 标记。

• 栈顶：高地址，由用户态 SP 指向；初始栈顶由 loader/内核在 exec 时设定，并受 arch_pick_mmap_layout() 等影响，会为栈预留空间并留出 stack guard gap。
• 栈底（当前）：即该 VMA 的 vm_start（低地址）；栈「向下长」即 vm_start 变小，VMA 向低地址扩展。
• 栈大小限制：由 RLIMIT_STACK（ulimit -s）提供，内核在扩展栈时用该限制做检查，超过则拒绝扩展并导致本次缺页处理失败，进而向用户态发 SIGSEGV。

栈与其它映射之间保留的间隔由全局变量 stack_guard_gap 控制（默认 256 页，即 4KB 页下 1MB）：

// mm/mmap.c
/* enforced gap between the expanding stack and other mappings. */
unsigned long stack_guard_gap = 256UL<<PAGE_SHIFT;

因此：栈溢出在内核侧的语义是——缺页发生在当前栈 VMA 的 vm_start 之下，且要么扩展会超过 RLIMIT_STACK，要么会侵入 stack_guard_gap 或其它映射，从而不允许扩展，只能返回错误并让上层发 SIGSEGV。

三、补充：mm_struct / task_struct / vm_area_struct 的关系（校对到当前内核）

为避免把旧资料中的字段名带入本文，这里先给出与当前内核（/Users/weli/works/linux）一致的结构关系。你在阅读后续缺页与栈扩展路径时，可以把这张图当作“对象关系索引”。

graph TB
    subgraph TASK[任务层]
      T[task_struct]
      TMM[mm]
      TAMM[active_mm]
    end

    subgraph MM[地址空间层]
      M[mm_struct]
      MMT[mm_mt\nMaple Tree of VMA]
      MPGD[pgd\npage table root]
      MLOCK[mmap_lock]
      MCOUNT[mm_users / mm_count]
      MSTAT[total_vm locked_vm stack_vm ...]
      MBOUND[start_code start_brk brk start_stack ...]
    end

    subgraph VMA[VMA层]
      V[vm_area_struct]
      VADDR[vm_start .. vm_end]
      VFLAGS[vm_flags]
      VFILE[vm_file / anon_vma]
    end

    subgraph PT[页表层 x86_64]
      PGD[PGD]
      P4D[P4D]
      PUD[PUD]
      PMD[PMD]
      PTE[PTE]
      PF[Page Frame]
    end

    T --> TMM --> M
    T --> TAMM --> M

    M --> MMT --> V
    M --> MPGD --> PGD
    M --> MLOCK
    M --> MCOUNT
    M --> MSTAT
    M --> MBOUND

    V --> VADDR
    V --> VFLAGS
    V --> VFILE

    PGD --> P4D --> PUD --> PMD --> PTE --> PF
    V -. address validity / permission .-> PTE

本图对应的关键校对点

• mm_struct 当前主组织结构是 mm_mt（Maple Tree），不是旧口径里的 mmap + mm_rb。
• mm_struct 的 VMA 锁字段是 mmap_lock，不是 mmap_sem。
• task_struct 里 mm / active_mm 的关系与经典描述一致。
• 缺页建立映射时，VMA 负责“地址区间与权限语义”，页表负责“虚拟地址到物理页”的具体映射。

核心结构体定义文件（对照阅读）

• struct mm_struct：include/linux/mm_types.h
• struct vm_area_struct：include/linux/mm_types.h
• struct task_struct：include/linux/sched.h
• mm_struct.mm_mt 的类型 struct maple_tree：include/linux/maple_tree.h
  • 字段出现位置：include/linux/mm_types.h（struct maple_tree mm_mt;）
  • Maple Tree 实现文件：lib/maple_tree.c

Maple Tree 与 VMA 的真实绑定关系（结构 + 流程）

上面的关系图强调了 mm_mt 与 VMA 的关联，这里把“结构体层面怎么存”说清楚：

1. mm_struct 里持有 struct maple_tree mm_mt（树容器）。
2. maple_tree 本体（struct maple_tree）只有锁、flags、ma_root 根指针，不直接内嵌 vm_area_struct。
3. ma_root 是编码过的 void * 入口：
   • 常见（多条目）情况：ma_root -> maple_node -> slot[] -> vma*
   • 单条目优化情况：ma_root 可直接承载条目（编码后的 vma*），不经过 maple_node
4. 真正的节点是 struct maple_node；节点里有 slot[]，并通过 maple_range_64 / maple_arange_64 维护 pivot[]（地址分界）。
5. 在 mm 场景中，slot[] 存放的是 struct vm_area_struct *（以 void * 形式存）。

graph TB
  MM["mm_struct"]
  MT["mm_mt: struct maple_tree"]
  ROOT["ma_root"]
  DIRECT["direct encoded entry<br/>(single-entry optimization)"]
  NODE["maple_node"]
  PIV["pivot array<br/>地址区间边界"]
  SLOTS["slot array<br/>value = vma*"]
  A["VMA_A*<br/>vm_start..vm_end"]
  B["VMA_B*<br/>vm_start..vm_end"]
  C["VMA_C*<br/>vm_start..vm_end"]

  MM --> MT --> ROOT
  ROOT --> NODE
  ROOT --> DIRECT --> A
  NODE --> PIV
  NODE --> SLOTS
  SLOTS --> A
  SLOTS --> B
  SLOTS --> C

创建（绑定）过程：地址区间 -> VMA 指针

在 mm/vma.h 的 vma_iter_store_gfp() 里，内核会：

• 用 __mas_set_range(&vmi->mas, vma->vm_start, vma->vm_end - 1) 设定 key 区间；
• 再用 mas_store_gfp(&vmi->mas, vma, gfp) 把 vma* 作为 value 存入 mm_mt。

因此绑定关系是：

• key = 虚拟地址范围 [vm_start, vm_end)（内部以 start..end-1 存）
• value = struct vm_area_struct *

查找过程：给定地址 -> 命中 VMA

vma_iterator 通过 mas_init(&vmi->mas, &mm->mm_mt, addr) 绑定到当前进程的 mm_mt， 随后 vma_find() 调 mas_find() 从 ma_root 开始查找：

• 若 ma_root 为直接条目，直接返回对应 vm_area_struct *；
• 若 ma_root 指向节点，则按 pivot 导航到 slot[]，再返回对应 vm_area_struct *。

这一点也解释了为什么当前内核文档口径应该写成：

• “Maple Tree (mm_mt) 按地址区间索引 VMA 指针”

而不是旧口径的“mmap 链表 + mm_rb 红黑树”主路径。

四、缺页时栈如何扩展：从查 VMA 到 expand_downwards

用户访问栈上尚未映射的地址时，CPU 触发缺页异常，进入架构相关的 fault 处理（如 x86-64 的 do_user_addr_fault），再通过通用层查找 VMA 并决定是否扩展栈。

4.1 查找 VMA 与「无 VMA 则尝试扩展栈」

在支持 CONFIG_LOCK_MM_AND_FIND_VMA 的路径上（如 x86-64），会调用 lock_mm_and_find_vma()（mm/mmap_lock.c）：

// mm/mmap_lock.c (约 251–286 行)
vma = find_vma(mm, addr);
if (likely(vma && (vma->vm_start <= addr)))
    return vma;

/* 地址落在某 VMA 起始之下，仅当该 VMA 是向下扩展的栈时才允许扩展 */
if (!vma || !(vma->vm_flags & VM_GROWSDOWN)) {
    mmap_read_unlock(mm);
    return NULL;   /* 上层会进入 bad_area，发 SIGSEGV */
}
// ...
if (expand_stack_locked(vma, addr))
    goto fail;

含义：若 addr 不在任何已有 VMA 内（或正好在栈 VMA 的 vm_start 之下），则只有当前「紧邻其上的」VMA 是 VM_GROWSDOWN（用户栈）时才尝试扩展；否则返回 NULL，缺页无法解析，最终发 SIGSEGV。

4.2 expand_stack_locked → expand_downwards

expand_stack_locked() 在向下扩展的配置下（常见配置）直接调用 expand_downwards()（mm/mmap.c 与 mm/vma.c）：

// mm/mmap.c
int expand_stack_locked(struct vm_area_struct *vma, unsigned long address)
{
    return expand_downwards(vma, address);
}

expand_downwards()（mm/vma.c 约 3024–3102 行）主要做三件事：

1. 检查 VM_GROWSDOWN，并做地址与 mmap_min_addr 等校验。
2. 强制 stack_guard_gap：若在 addr 下方存在其它可访问的 VMA，且与当前栈的间距小于 stack_guard_gap，则拒绝扩展，返回 -ENOMEM。
3. 在允许扩展的前提下，调用 acct_stack_growth() 做栈限制检查；通过则更新 VMA 的 vm_start（及相关结构），完成栈的向下延伸。

4.3 栈限制检查：acct_stack_growth

栈能扩展的「总大小」由 rlimit(RLIMIT_STACK) 限制（对应 ulimit -s）。扩展前在 acct_stack_growth() 中统一检查（mm/vma.c 约 2898–2930 行）：

// mm/vma.c
static int acct_stack_growth(struct vm_area_struct *vma,
                             unsigned long size, unsigned long grow)
{
    struct mm_struct *mm = vma->vm_mm;
    // ...
    /* Stack limit test */
    if (size > rlimit(RLIMIT_STACK))
        return -ENOMEM;
    // ...
    return 0;
}

这里 size 是扩展后的栈 VMA 总大小。一旦「当前栈已用 + 本次要扩展」超过 RLIMIT_STACK，就返回 -ENOMEM，expand_downwards() 失败，缺页路径无法解析该地址，上层会进入 bad_area 并给进程发 SIGSEGV。也就是说：触顶 = 扩展被 rlimit 拒绝，而不是「多缺了一次页」本身；缺页只是触发这次检查的契机。

4.4 扩展成功后：匿名页分配

扩展栈 VMA 只调整了虚拟区间（vm_start 下移），并未立刻分配物理页。物理页在第一次访问该新区间内的地址时，由通用缺页逻辑分配：此时 VMA 已包含该地址，find_vma 会命中栈 VMA，进入 handle_mm_fault() → __handle_mm_fault() → handle_pte_fault()，对匿名、未映射的 PTE 走 do_anonymous_page()（mm/memory.c 约 5022 行），分配匿名页并建立映射。因此：每第一次接触一个新页，产生一次缺页；栈用量由 SP 下移多少决定，缺页次数则等于「新被触及的页数」，二者相关但不等价。

五、缺页与「触顶」的完整路径小结

1. 用户访问栈下未映射地址 → CPU #PF。
2. arch（如 arch/x86/mm/fault.c）→ do_user_addr_fault() → lock_mm_and_find_vma(mm, address, regs)。
3. mm/mmap_lock.c：find_vma(mm, addr)；若 addr 在栈 VMA 之下且该 VMA 为 VM_GROWSDOWN，则 expand_stack_locked(vma, addr)。
4. mm/mmap.c：expand_stack_locked() → mm/vma.c：expand_downwards() → 检查 stack_guard_gap，再 acct_stack_growth() 检查 size > rlimit(RLIMIT_STACK)；若通过则扩展 vma->vm_start。
5. 若扩展失败（rlimit 或 guard gap），lock_mm_and_find_vma 返回 NULL，arch 层进入 bad_area → 向用户态发 SIGSEGV。
6. 若扩展成功，返回用户态重试指令，再次访问同一地址时已落在栈 VMA 内，走正常缺页：mm/memory.c handle_mm_fault() → __handle_mm_fault() → handle_pte_fault() → do_anonymous_page()，分配物理页并建立 PTE。

因此：「224 次缺页就崩溃」 表示整次进程运行共发生 224 次缺页（包括栈、代码段、库、guard 等）；最后一次（或临界一次） 是访问到了不允许扩展的区域（超过 RLIMIT_STACK 或进入 guard gap），内核拒绝扩展并发 SIGSEGV，而不是「第 224 次缺页时多分配了一页栈」。

六、页缓存、物理页与缺页次数

• 物理页：进程退出后，部分物理页可能仍留在系统（匿名页回收策略、文件页的 page cache）。新进程再次运行同一程序时，可能复用这些物理页，但页表是 per-process 的，进程退出后页表销毁，新进程必须重新建立虚拟地址到物理页的映射，因此仍会触发缺页。
• 栈是匿名映射：栈不对应文件，不能像文件映射那样用 (inode, offset) 做 page cache 的键。第二次运行缺页减少，主要来自代码段、共享库等文件映射的缓存命中，以及系统中仍有可复用的物理页被新进程映射；栈区本身每个进程独立，只是若系统未立刻回收，新进程可能复用刚释放的物理页，缺页数会少一些。
• 内核的页缓存与物理页复用是全局的，不按进程或程序名区分；多进程可共享同一物理页（如代码段、共享库），体现的是「尽量共享」的设计。

七、ARM64 与页大小、THP

在 ARM64 上，许多配置使用 16KB 甚至 64KB 的页，且可能启用透明大页（THP），同样大小的栈所需页数远少于 x86-64 的 4KB 页，因此同一次运行的缺页次数会少很多（例如首次运行就只看到约 226 次）。这与「第二次运行因缓存而减少」是不同原因：前者是架构与页大小，后者是物理页/页表复用。

八、如何复现与对照内核

• 查看栈限制与页大小：ulimit -s、getconf PAGESIZE。
• 用 stack-vs-heap-benchmark 复现：make stack_overflow_test，perf stat -e page-faults ./stack_overflow_test crash。该程序先递归消耗约 6–7MB 栈，再在剩余空间内用汇编每次 push 8KB 直到触顶，便于观察「总栈接近 8MB 时的一次失败扩展」与缺页计数的关系。
• 对照阅读内核（以你本机路径为准，例如 /Users/weli/works/linux）：
  • mm/mmap_lock.c：lock_mm_and_find_vma() 中 find_vma 与 expand_stack_locked() 的调用；
  • mm/mmap.c：stack_guard_gap、expand_stack_locked()、expand_stack()；
  • mm/vma.c：expand_downwards()、acct_stack_growth() 及 rlimit(RLIMIT_STACK) 检查；
  • mm/memory.c：handle_mm_fault()、__handle_mm_fault()、do_anonymous_page()；
  • arch/x86/mm/fault.c：do_user_addr_fault() 及对 lock_mm_and_find_vma() 的调用。

九、结论

• 用户栈在内核中是一个 VM_GROWSDOWN 的 VMA；扩展时受 rlimit(RLIMIT_STACK) 和 stack_guard_gap 约束。
• 缺页时，若地址落在栈 VMA 之下，内核通过 expand_stack_locked → expand_downwards → acct_stack_growth 决定是否扩展；超过 rlimit 或违反 guard gap 则拒绝扩展，本次缺页无法解析，进程收到 SIGSEGV。
• 缺页次数 = 本次运行中「首次触及」的页数（栈、代码、库、guard 等合计），与「栈总用量」相关但不等同；触顶由扩展被内核拒绝决定，而非缺页计数达到某个值。
• 第二次运行缺页减少主要来自物理页/文件映射的复用；ARM64 下首次运行缺页就较少则主要来自更大页与 THP。

若你希望把栈溢出、缺页与 rlimit 的结论落实到具体可跑的程序上，可用上述 benchmark 项目配合本机内核源码一起对照。

ccoctl 是 OpenShift 的云凭据操作符 (CCO) 实用程序，其主要用途是在手动模式下，为各个集群组件在云提供商上创建和管理精细化的短期权限凭证，从而避免在集群中存储高权限的长期凭证，提升集群安全性。

简单来说，它允许您为 OpenShift 的每个组件（如镜像仓库、存储驱动、Ingress Controller 等）分别创建独立的、最小权限的云账号，而不是使用一个拥有全局权限的管理员账号。

一、为什么需要 ccoctl？与默认模式的对比

核心作用

ccoctl 主要用在需要最高安全标准的场景。它将云凭证的管理从集群内部转移到集群外部，实现了更严格的权限控制：

• 实现短期凭证：为 AWS、GCP 等云平台配置基于 OIDC 的短期凭证（如 AWS STS、GCP Workload Identity）。集群组件使用这些临时令牌来访问云 API，凭证会自动轮换，风险更低。
• 避免存储管理员凭证：在手动模式下，集群的 kube-system 命名空间中不会存储高权限的管理员级云凭证，大大降低了凭证泄露的风险。
• 管理长期凭证：对于 IBM Cloud 或 Nutanix 等平台，ccoctl 也用于在安装过程中配置由外部管理的长期凭证。
• 清理资源：在集群卸载后，可以使用 ccoctl 来删除它在安装时创建的云资源（如 IAM 角色、OIDC 提供商和 S3 存储桶）。

简单来说：不使用 ccoctl 的安装过程更简单快捷，但安全性较低；使用 ccoctl 的过程更复杂，但安全性最高，符合企业级安全最佳实践。

两种方式对比

建议：有严格安全合规要求或希望采用最小权限原则时选用 ccoctl；开发测试、POC 或优先便利性时，默认 Mint 模式即可。

二、如何使用 ccoctl

获取 ccoctl 二进制

RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl.rhel8" -a ~/.pull-secret
chmod 775 ccoctl.rhel8
./ccoctl --help

主要场景：为 AWS STS 集群创建资源

1. 创建密钥对：./ccoctl aws create-key-pair
2. 创建 OIDC 身份提供商和 S3 存储桶：./ccoctl aws create-identity-provider --name=<cluster-name> --region=<aws-region> --public-key-file=<path-to-public-key>
3. 提取 CredentialsRequests：oc adm release extract --credentials-requests --cloud=aws --to=./credrequests <your-release-image>
4. 为每个组件创建 IAM 角色：./ccoctl aws create-iam-roles --name=<cluster-name> --region=<aws-region> --credentials-requests-dir=./credrequests --identity-provider-arn=<arn-of-oidc-provider>

完成后将生成的 manifest 复制到安装目录的 manifests 和 tls 目录。集群卸载后清理：./ccoctl aws delete --name=<cluster-name> --region=<aws-region>。

三、STS 工作流程：从准备到运行时

这是云原生安全的最佳实践之一，结合 OIDC 身份联邦、Kubernetes ServiceAccount 和 云 IAM 角色，以 AWS STS 为例说明。

核心架构概览（双向信任链）

1. OpenShift 集群信任 AWS：集群通过 OIDC 提供商对外宣称「我是谁」。
2. AWS 信任 OpenShift：IAM 角色配置为只信任特定的 OpenShift ServiceAccount。
3. 组件自动换证：组件通过扮演角色获取临时令牌，无需人工干预。

前期准备（ccoctl 搭建）

1. 创建 OIDC 提供商：ccoctl 在 AWS 上创建公钥端点（通常放在 S3），AWS 用其验证集群签发的 ServiceAccount 令牌。
2. 创建 IAM 角色与信任策略：为每个需要云权限的组件创建一个 IAM 角色，信任策略只允许特定的 OpenShift ServiceAccount 扮演该角色。示例：

{
  "Effect": "Allow",
  "Principal": { "Federated": "arn:aws:iam::123456789:oidc-provider/<s3-bucket-name>" },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": { "<s3-bucket-name>:sub": "system:serviceaccount:openshift-ingress:router" }
  }
}

集群运行时（自动获取凭证）

以 Ingress Controller Pod 为例：

1. Pod 挂载带注解的 ServiceAccount：例如 sts.amazonaws.com/role-arn: "arn:aws:iam::123456789:role/openshift-ingress-role"，无 AWS Secret。
2. API Server 签发 JWT：Kubelet 向 API Server 请求为该 ServiceAccount 签发 JWT，签名私钥即 ccoctl 生成的那对密钥中的私钥。
3. Pod 向 AWS STS 发起 AssumeRoleWithWebIdentity：SDK 自动携带 JWT 与 Role ARN。
4. STS 验证并颁发临时凭证：验证 JWT 签名（用 OIDC 公钥）、校验 sub 与信任策略，通过后返回 AccessKeyId、SecretAccessKey、SessionToken（通常 1 小时有效）。
5. Pod 使用临时凭证调用 AWS API，过期前 SDK 自动用同一 JWT 换新凭证，对应用透明。

为什么这个模式更安全？

• 无长期凭证：集群内没有永久有效的 AccessKey/SecretKey。
• 权限最小化：每个组件只能拿到自己 Role 的权限。
• 凭证自动轮换：泄露的临时凭证在 1 小时内失效。
• 身份绑定：凭证与特定 Pod/ServiceAccount 绑定，无法被集群外冒用。

四、技术细节：公钥、IAM Role 数量与 SA/Role 关系

公钥端点：签名验证，不是数据加密

使用的是私钥签名、公钥验签的数字签名过程：

• ccoctl：生成密钥对；私钥由集群 API Server 保管并用于签发 JWT；公钥上传到 S3（OIDC 公钥端点）。
• 流程：API Server 用私钥对 JWT 签名 → AWS STS 从 OIDC 端点取公钥验签，确认令牌来自可信集群且未被篡改。核心是身份真实性验证，不是传输保密。

IAM Role 数量：约 10–15 个

ccoctl 为每个需要调用云 API 的组件创建一个独立 IAM Role，不使用 IAM User。典型组件包括：Cluster API Provider、Image Registry、Ingress Controller、Storage (CSI)、Machine Config Operator、Cloud Network Config 等。

ServiceAccount 与 IAM Role：扮演与被扮演

• ServiceAccount：集群内「谁」在请求。
• IAM Role：云上「可以做什么」的权限集合。
• 信任策略：规定只允许特定 OIDC 端点、特定 ServiceAccount（如 openshift-ingress:router）来扮演该 Role。SA 拿 JWT 来「敲门」，Role 验证通过后才允许暂时扮演。

整体关系与流程图

graph TD
    subgraph pre_ccoctl["安装前 (由 ccoctl 执行)"]
        A[ccoctl] --> B1(生成密钥对)
        A --> B2(为每个组件创建 IAM Role)
        A --> B3(上传公钥到 S3 桶)
        A --> B4(在 AWS 创建 OIDC IdP<br/>指向 S3 桶)
    end

    subgraph aws_cloud["AWS 云平台"]
        S3["S3 桶 (公钥端点)"] --> OIDC["AWS OIDC 身份提供商"]
        subgraph iam["IAM"]
            direction LR
            Role_Ingress["IAM Role Ingress<br/>信任策略: 限定 ServiceAccount"]
            Role_Registry["IAM Role Registry<br/>信任策略: 限定 ServiceAccount"]
        end
    end

    subgraph ocp["OpenShift 集群"]
        direction TB
        API["Kubernetes API Server<br/>持有 私钥"] --> SA_Ingress["ServiceAccount: router<br/>Annotation: role-arn=Role_Ingress"]
        SA_Registry["ServiceAccount: registry<br/>Annotation: role-arn=Role_Registry"]
        Pod_Ingress["Pod: Ingress Controller"] -->|挂载| SA_Ingress
        Pod_Registry["Pod: Image Registry"] -->|挂载| SA_Registry
    end

    subgraph runtime["运行时 (自动流程)"]
        direction LR
        Req1["Pod 请求 AWS API"] --> Req2["SDK 自动读取 JWT 令牌"]
        Req2 --> Req3["SDK 向 STS 发送 AssumeRoleWithWebIdentity 请求<br/>携带 JWT 令牌和 IAM Role ARN"]
    end

    subgraph sts_flow["AWS STS 验证与响应"]
        Val1["STS 接收请求"] --> Val2["根据 JWT 的 iss 字段<br/>找到 OIDC IdP"]
        Val2 --> Val3["OIDC IdP 从 S3 获取公钥<br/>验证 JWT 签名"]
        Val3 --> Val4{验证通过?}
        Val4 -->|是| Val5["校验 JWT 的 sub 字段<br/>是否匹配 IAM Role 信任策略"]
        Val5 -->|是| Val6["STS 生成临时凭证<br/>(AK/SK/Token) 返回给 Pod"]
    end

    Pod_Ingress -.-> Req1
    Val6 -.-> Pod_Ingress

要点：私钥在集群内签名，公钥在 S3 供 AWS 验签；每个组件一个 Role；SA 通过 Annotation 与 Role 信任策略建立绑定；运行时 Pod 用 JWT 向 STS 申请扮演 Role 并获得临时凭证。

五、JWT 令牌 vs STS 临时凭证

关系概括：JWT 是「身份证」，STS 临时凭证是「通行证」。Pod 先亮出身份证证明「我是谁」，再换取能真正调用云 API 的通行证。

对比表

类比：机场安检

JWT 与 STS 关系（Mermaid）

graph TB
    subgraph "OpenShift 集群内部"
        Pod[Pod/容器]
        SA[ServiceAccount<br/>router]
        JWT[JWT 令牌<br/>身份证明]
        API[Kubernetes API Server<br/>持有私钥]
        Pod --> SA
        SA -.->|挂载| JWT
        API -->|用私钥签发| JWT
    end

    subgraph "AWS STS 验证过程"
        direction TB
        Step1[接收 AssumeRoleWithWebIdentity 请求<br/>携带 JWT 令牌 + IAM Role ARN]
        Step2[从 OIDC 端点获取公钥]
        Step3[用公钥验证 JWT 签名]
        Step4[检查 JWT.sub 是否匹配<br/>IAM Role 信任策略]
        Step5[验证通过 → 生成临时凭证]
        Step1 --> Step2 --> Step3 --> Step4 --> Step5
    end

    subgraph "STS 临时凭证"
        Temp_Cred[AccessKeyId + SecretAccessKey + SessionToken + Expiration]
    end

    JWT -.->|提交身份证明| Step1
    Step5 -->|返回| Temp_Cred
    Temp_Cred -->|SDK 缓存| Pod

时序流程

sequenceDiagram
    participant P as Pod
    participant K as K8s API Server
    participant STS as AWS STS
    participant S3 as S3/其他AWS服务

    K->>P: 用私钥签发 JWT 并挂载到 Pod
    P->>STS: AssumeRoleWithWebIdentity(JWT + Role ARN)
    STS->>STS: 从 OIDC 获取公钥、验签、检查 sub
    STS-->>P: 返回临时凭证
    P->>S3: 调用 API（带临时凭证）
    Note over P: 1 小时后 SDK 用同一 JWT 换新凭证

三者的层级关系

graph RL
    subgraph "第4层：云资源操作"
        API_Calls[AWS API 调用<br/>S3/EC2/ELB]
    end
    subgraph "第3层：临时权限凭证"
        Temp_Cred[STS临时凭证<br/>1小时有效期]
    end
    subgraph "第2层：集群内身份"
        JWT[JWT令牌<br/>K8s API Server 签发]
    end
    subgraph "第1层：底层基础设施"
        KeyPair[密钥对<br/>私钥: K8s / 公钥: S3]
        IAM_Role[IAM Role<br/>权限策略+信任策略]
    end
    KeyPair -->|私钥签发| JWT
    KeyPair -->|公钥验证| Temp_Cred
    IAM_Role -->|信任策略允许| Temp_Cred
    JWT -->|证明身份换取| Temp_Cred
    Temp_Cred -->|授权执行| API_Calls

核心关系总结（图示）

graph TD
    subgraph "JWT令牌 vs STS临时凭证"
        A[JWT令牌] -->|作用| A1["证明身份<br/>'我是openshift-ingress:router'"]
        A -->|颁发者| A2["Kubernetes API Server"]
        A -->|验证者| A3["AWS STS"]
        A -->|生命周期| A4["Pod生命周期<br/>只要Pod在就有效"]
        B[STS临时凭证] -->|作用| B1["授权操作<br/>'我可以创建负载均衡器'"]
        B -->|颁发者| B2["AWS STS"]
        B -->|验证者| B3["AWS各服务<br/>(S3/EC2/ELB等)"]
        B -->|生命周期| B4["1小时<br/>自动轮换"]
        A -.->|换取| B
    end

一句话：JWT 管「你是谁」，临时凭证管「你能做什么」；两者职责分明，流程自动化。

六、IAM Role 的两种核心策略与权限来源

重要：这些 IAM Role 的权限与 IAM User 无关，来自角色自身附加的权限策略。

双重策略结构

每个 IAM Role 包含两个独立策略：

graph TB
    subgraph IAM角色 [IAM Role]
        direction TB
        TP[信任策略 Trust Policy<br/>定义：谁可以扮演这个角色]
        PP[权限策略 Permission Policy<br/>定义：扮演后可以做什么]
    end
    TP --> 验证[验证：你是谁？]
    PP --> 授权[授权：你能做什么？]

• 信任策略：只允许来自特定 OIDC 提供商、且 JWT 的 sub 为特定 ServiceAccount 的请求者扮演该角色。
• 权限策略：定义扮演后能执行哪些 AWS 操作（如 Image Registry 的 S3 操作）。

在 ccoctl 模式下完全不使用 IAM User：ccoctl 为每个组件创建 IAM Role，直接附加权限策略与信任策略；Pod 通过 JWT 扮演角色，获得的是角色自身的权限。

信任策略的完整工作机制

sequenceDiagram
    participant Pod as Pod (Ingress)
    participant STS as AWS STS
    participant Role as IAM Role (Ingress)

    Pod->>STS: AssumeRoleWithWebIdentity(JWT + Role ARN)
    Note over STS: STS 验证 JWT 签名（用 OIDC 公钥）
    STS->>Role: 读取 Role 的信任策略
    Note over STS: 检查 JWT 身份是否匹配信任策略
    alt 验证通过
        STS-->>Pod: 返回临时凭证
        Pod->>AWS API: 用临时凭证调用 API
    else 验证失败
        STS-->>Pod: 拒绝请求
    end

信任策略在扮演阶段由 STS 验证；权限策略在实际调用各 AWS 服务时验证；两者独立且缺一不可。

ccoctl 的权力从哪来？

ccoctl 的权力是被赋予的：运行 ccoctl 的人（或系统）必须提供一个具有足够 AWS 权限的 IAM 用户或角色（例如能调用 iam:CreateRole、iam:CreateOpenIDConnectProvider、s3:PutObject 等）。有了该凭证后，ccoctl 按 OpenShift 的 CredentialsRequest 为每个组件创建 IAM Role，并附加权限策略与信任策略。

graph LR
    A[运行 ccoctl] --> B[读取 CredentialsRequest]
    B --> C[为每个组件准备 IAM Role]
    C --> D[创建 IAM Role]
    D --> E[附加权限策略]
    D --> F[配置信任策略]

七、运行态集群的权限闭环与安全实践

用于运行 ccoctl 的高权限用户，在集群安装完成后可以彻底退出：集群运行时不需要、也不会用到该用户的凭证。

运行态权限闭环

graph TB
    subgraph "安装阶段 (ccoctl 执行)"
        Admin[管理员持有<br/>高权限 IAM User]
        Admin -->|执行 ccoctl| Create[创建所有 IAM Role<br/>和 OIDC 提供商]
        Create -->|完成后| Done[高权限用户凭证<br/>可以安全删除或封存]
    end
    subgraph "运行阶段 (集群运行时)"
        Pod[Pod] -->|JWT 令牌| STS[AWS STS]
        STS -->|验证通过后颁发| Temp[临时凭证]
        Temp -->|权限来自| Role[IAM Role 自身的权限策略]
        Role -->|不涉及| AdminUser[安装时的高权限用户]
    end
    Done -.->|不再使用| AdminUser

原因简要说明：权限已固化在各 IAM Role 的权限策略与信任策略中；集群组件通过 JWT → STS → 扮演 Role → 获得临时凭证 → 调用 API，整条链无需安装时的高权限用户；临时凭证的权限来自被扮演的 Role，而非创建 Role 的用户。

安全最佳实践：安装后清理

graph LR
    subgraph "安装完成后"
        A[高权限 IAM User] --> B{选择处理方式}
        B --> C[彻底删除该用户]
        B --> D[禁用 Access Key]
        B --> E[轮换并封存凭证<br/>仅用于灾难恢复]
    end
    subgraph "运行态集群"
        F[所有组件] --> G[只使用临时凭证]
        H[管理员日常操作] --> I[使用更低权限的<br/>只读或审计账号]
    end

建议：安装成功后立即删除或禁用该高权限用户的 Access Key；日常管理使用只读或审计账号；必要时可用 STS 临时凭证来运行 ccoctl，避免长期高权限用户。

与 Mint 模式对比

八、kube-apiserver 与 OIDC

JWT 的签发与公钥提供由 kube-apiserver 完成：

1. 持有私钥：加载 ccoctl 生成并交给集群的私钥（如 /etc/kubernetes/pki/sa.key）。
2. 签发 JWT：当 Pod 挂载 ServiceAccount 并请求令牌时，使用 TokenRequest API 签发绑定服务账户令牌（Bound Service Account Token）。
3. 提供公钥端点：通过 /.well-known/openid-configuration、/openid/v1/jwks 等对外提供公钥，供 AWS STS 验签。

graph LR
    subgraph OpenShift 集群
        API[kube-apiserver]
        KeyPair[密钥对<br/>私钥: sa.key<br/>公钥: sa.pub]
        SA[ServiceAccount]
        Pod[Pod]
        Token[JWT 令牌]
        API -- 持有 --> KeyPair
        SA -- 请求令牌 --> API
        API -- 使用私钥签发 --> Token
        Token -- 挂载到 --> Pod
    end
    subgraph 外部
        STS[AWS STS]
        JWKS_Endpoint[JWKS 公钥端点]
    end
    API -- 提供公钥 --> JWKS_Endpoint
    Pod -- 发送 JWT 令牌 --> STS
    STS -- 从端点获取公钥、验签 --> STS

kubelet 会监控挂载的短期令牌有效期，在过期前通过 TokenRequest API 向 apiserver 请求新令牌，实现无缝轮换。

九、AWS 对 OIDC 的支持与标准化

AWS 主动实现了 OIDC 开放标准，才能与 Kubernetes/OpenShift 无缝集成。

AWS 对 OIDC 的支持

graph TB
    subgraph oidc_open_std["开放标准 OIDC"]
        OIDC_Core["OIDC 核心规范"]
        OIDC_Core -->|定义| JWKS[JWKS 公钥格式]
        OIDC_Core -->|定义| JWT[JWT 令牌结构]
    end
    subgraph k8s_ocp["Kubernetes/OpenShift"]
        K8s[实现 OIDC 身份提供商]
        K8s -->|提供| K8s_JWKS[公钥端点]
        K8s -->|签发| K8s_JWT[JWT 令牌]
    end
    subgraph aws_fed["AWS"]
        AWS_Federation["AWS 实现 OIDC 身份联邦"]
        AWS_Federation -->|支持| IAM_OIDC[IAM OIDC 身份提供商]
        AWS_Federation -->|支持| STS_OIDC[STS AssumeRoleWithWebIdentity]
        AWS_Federation -->|验证| AWS_Validation[OIDC 令牌验证]
    end
    K8s_JWKS --> IAM_OIDC
    K8s_JWT --> STS_OIDC
    STS_OIDC --> AWS_Validation

AWS 的三件关键实现：① IAM OIDC 身份提供商（ccoctl 在 AWS 上创建）；② STS AssumeRoleWithWebIdentity API；③ IAM Role 信任策略中的 OIDC 条件键（如 sub、aud、iss）。GCP、Azure、阿里云等也支持类似 OIDC 联邦，逻辑一致：集群提供 OIDC 端点 → 云厂商创建 OIDC IdP → 角色配置信任策略 → Pod 用 JWT 换临时凭证。

标准化的价值

graph TD
    subgraph k8s_clusters["Kubernetes 集群"]
        Cluster1[OpenShift 集群]
        Cluster2[原生 K8s]
        Cluster3[其他发行版]
    end
    subgraph oidc_norm["OIDC 标准"]
        OIDC_Spec["OIDC 核心规范"]
    end
    subgraph cloud_vendors["云厂商"]
        Cloud_AWS[AWS]
        Cloud_GCP[GCP]
        Cloud_Azure[Azure]
    end
    Cluster1 --> OIDC_Spec
    Cluster2 --> OIDC_Spec
    Cluster3 --> OIDC_Spec
    OIDC_Spec --> Cloud_AWS
    OIDC_Spec --> Cloud_GCP
    OIDC_Spec --> Cloud_Azure

十、短期 vs 长期凭证与数据格式

短期与长期凭证对比

安装阶段 STS 版本需要更多权限（创建 OIDC、IAM Role 等）是一次性「建设成本」；运行阶段普通版本长期存在的多凭证才是安全命门。STS 用安装时短暂的「多」，换运行时永久的「少」和「短」。

数据格式对比

• 长期凭证：2 个字段 — AccessKeyId（以 AKIA 开头）、SecretAccessKey；无过期时间。
• 临时凭证：3 个字段 — AccessKeyId（以 ASIA 开头）、SecretAccessKey、SessionToken，以及 Expiration。调用 AWS API 时必须同时携带三者；缺少 SessionToken 会被拒绝。

SessionToken 是 STS 临时凭证的关键：证明凭证由 STS 合法颁发、在有效期内且未超出权限范围。

SessionToken 的验证

验证是「接力」的：签发由 STS 在 AssumeRoleWithWebIdentity 时完成；每次 API 调用时，目标服务（如 S3、EC2）将凭证转交 AWS 统一认证系统，检查 SessionToken 是否合法、未过期、未吊销，并评估权限与条件。这样既能及时吊销，又保证审计与动态条件评估有效。

每次 API 调用时，AWS 内部的验证流程可概括为：

graph TD
    A[收到API请求] --> B[提取凭证 AccessKey + SessionToken]
    B --> C{SessionToken存在?}
    C -->|否| D[当作长期凭证处理]
    C -->|是| E[查询STS服务端状态]
    E --> F{凭证状态}
    F -->|已过期| G[拒绝请求 ExpiredToken]
    F -->|已吊销| H[拒绝请求 AccessDenied]
    F -->|有效| I[继续验证]
    I --> J[验证请求签名]
    J --> K{签名正确?}
    K -->|否| L[拒绝请求]
    K -->|是| M[评估IAM权限]
    M --> N{操作允许?}
    N -->|否| O[拒绝请求 AccessDenied]
    N -->|是| P[执行操作]

SessionToken 验证时序

sequenceDiagram
    participant P as Pod
    participant STS as AWS STS
    participant S3 as AWS S3
    participant Auth as AWS 统一认证系统

    P->>STS: AssumeRoleWithWebIdentity(JWT)
    STS-->>P: 返回临时凭证(含SessionToken)
    STS->>Auth: 同步凭证状态(有效期/权限)

    P->>S3: PutObject(带临时凭证)
    S3->>Auth: 请求验证凭证
    Auth->>Auth: 检查SessionToken有效性及权限
    Auth-->>S3: 验证结果
    S3-->>P: 操作结果

十一、缓存与验证：不会每次调用 AssumeRole

集群不会每次访问都调用 AssumeRole。凭证使用是一次 AssumeRole，多次使用，并有过期前自动刷新。

缓存机制

graph TD
    subgraph "第1层：Pod 内 SDK 缓存"
        A[Pod 首次调用 AWS API] --> B[SDK 检查内存缓存]
        B -->|无有效凭证| C[调用 AssumeRoleWithWebIdentity]
        C --> D[STS 返回临时凭证，有效期 1 小时]
        D --> E[SDK 将凭证缓存到内存]
        E --> F[使用凭证调用目标 API]
    end
    subgraph "第2层：后续 API 调用"
        G[后续 API 请求] --> H[SDK 检查内存缓存]
        H -->|有有效凭证| I[直接使用缓存凭证]
        I --> J[调用目标 API]
    end
    subgraph "第3层：过期前自动刷新"
        K[凭证剩余约 5 分钟] --> L[SDK 异步刷新]
        L --> M[后台 AssumeRoleWithWebIdentity]
        M --> N[更新内存缓存]
        N --> O[对应用完全透明]
    end

因此：是否每次访问都 AssumeRole？ 否，只有首次（或过期后）才调用。凭证用多久？ 1 小时，SDK 在过期前约 5 分钟自动刷新。性能影响？ 与长期凭证无异，绝大多数请求命中缓存。

何时会重新 AssumeRole？

graph LR
    A[触发重新 AssumeRole 的场景] --> B[首次启动]
    A --> C[凭证自然过期]
    A --> D[Pod 重建]
    A --> E[SDK 刷新失败后重试]
    A --> F[强制刷新配置]
    B --> G[需要新凭证]
    C --> G
    D --> G
    E --> G
    F --> G
    G --> H[调用 AssumeRole]

即：首次启动、凭证自然过期、Pod 重建、SDK 刷新失败后重试、或显式配置强制刷新时。

获取 vs 验证

凭证获取有缓存（约 1 小时一次，由 SDK 管理）；凭证验证每次 API 调用都会进行（目标服务向 AWS 认证系统验证 SessionToken、签名与权限）。这样既能及时吊销、满足动态策略与审计，又通过服务端缓存和边缘节点将单次验证延迟控制在很低水平。

graph TB
    subgraph "凭证生命周期"
        Get[获取凭证 AssumeRole] --> Cache[缓存凭证 Pod 内存]
        Cache --> Use1[第1次调用]
        Cache --> Use2[第2次调用]
        Cache --> Use3[第N次调用]
    end
    subgraph "每次调用时的验证"
        Use1 --> Validate1[AWS 服务验证 SessionToken]
        Use2 --> Validate2[AWS 服务验证 SessionToken]
        Use3 --> ValidateN[AWS 服务验证 SessionToken]
    end

十二、完整链条总览：数据与端点

阶段概览

• 阶段 1（ccoctl）：提取 CredentialsRequest、生成密钥对、向 S3 上传 OIDC 配置与公钥、创建 OIDC 提供商、为每个组件创建 IAM Role（含信任策略与权限策略）、输出 Secret YAML。
• 阶段 2（运行时）：Pod 挂载 SA → apiserver 签发 JWT → Pod 首次调用时 SDK 向 STS 发送 AssumeRoleWithWebIdentity(JWT + Role ARN) → STS 从 OIDC 取公钥验签、检查 sub → 返回临时凭证 → Pod 用临时凭证调用各 AWS 服务。
• 阶段 3（每次调用）：目标服务将凭证交 AWS 统一认证验证 SessionToken、权限与条件。

完整时序图

sequenceDiagram
    participant Admin as 管理员
    participant CCO as ccoctl
    participant S3 as AWS S3
    participant IAM as AWS IAM
    participant OIDC as AWS OIDC Provider
    participant API as kube-apiserver
    participant Pod as Pod (Ingress)
    participant STS as AWS STS
    participant Service as AWS Service (ELB)

    Note over Admin,Service: 阶段1：安装准备
    Admin->>CCO: 提取 CredentialsRequest、生成密钥对
    CCO->>S3: PUT OIDC 配置与公钥
    CCO->>IAM: CreateOpenIDConnectProvider、CreateRole、PutRolePolicy
    CCO->>Admin: 输出 Secret YAML
    Admin->>API: oc apply manifests

    Note over Admin,Service: 阶段2：集群运行时
    Pod->>API: 挂载 ServiceAccount
    API-->>Pod: JWT 令牌
    Pod->>STS: AssumeRoleWithWebIdentity(JWT + Role ARN)
    STS->>OIDC: 获取公钥
    STS->>STS: 验签、检查 sub
    STS-->>Pod: 临时凭证
    Pod->>Service: 调用 AWS API(带临时凭证)
    Service->>STS: 验证 SessionToken
    Service-->>Pod: 返回结果

    Note over Pod,Service: 过期前 SDK 后台用同一 JWT 换新凭证

关键端点

总结

• ccoctl 在手动模式下为各组件在云上创建并管理精细化、短期权限凭证，避免在集群内存储高权限长期凭证。
• STS 流程：OIDC + ServiceAccount + IAM Role 形成双向信任；Pod 用 JWT 向 STS 证明身份，换取 1 小时有效的临时凭证；公钥用于验签，不涉及数据加密。
• IAM Role 的权限来自角色自身的权限策略与信任策略，与 IAM User 无关；ccoctl 的执行权限来自运行它的管理员所持凭证。
• 运行时不需要安装时的高权限用户，建议安装后删除或禁用该用户，日常使用低权限账号。
• JWT 管身份，STS 临时凭证管权限；临时凭证含 SessionToken，调用 API 必须携带；获取有 SDK 缓存（约 1 小时一次），验证每次请求都会进行。
• kube-apiserver 签发 JWT 并暴露公钥；AWS 通过 OIDC 标准与 Kubernetes 对接，实现跨系统信任传递。

整体可概括为：一次创建（ccoctl），多次使用（SDK 缓存），每次验证（SessionToken），是 OpenShift 在公有云上实现最小权限与无长期凭证的典型生产级方式。

perf 子系统和 eBPF 并非两个孤立的子系统，而是共享基础设施、互相协作的伙伴。本文从两者在内核中的协作关系出发，再对比它们在「埋点」与数据处理思路上的本质区别，并对照主线内核代码做简要核对。

一、perf 与 eBPF 的紧密关系

1. 共享内核基础设施：perf_events 是基石

eBPF 的很多核心功能都建立在 perf_events 子系统提供的机制之上；perf_events 为 eBPF 的高效数据输出和硬件性能计数读取提供了通道。

数据输出通道：BPF_MAP_TYPE_PERF_EVENT_ARRAY

当 eBPF 程序需要向用户空间发送大量数据时（例如追踪每次系统调用的参数），通常不直接操作文件或网络，而是通过一类特殊的 eBPF Map——BPF_MAP_TYPE_PERF_EVENT_ARRAY。

• 工作原理：该 Map 的每个元素对应一个 perf_event 的文件描述符。eBPF 程序通过辅助函数 bpf_perf_event_output() 把数据写入该 Map，内核会将这些数据写入对应 perf 事件的环形缓冲区（ring buffer）。
• 优势：复用 perf 子系统的内核-用户空间数据传输机制，实现无锁、高性能的数据通路，无需为 eBPF 再实现一套类似设施。

内核中该 Map 类型的实现位于 kernel/bpf/arraymap.c，例如 perf_event_array_map_ops（perf_event_fd_array_get_ptr 等）负责将 Map 中的 fd 解析为 perf_event 指针并与 ring buffer 关联；kernel/bpf/verifier.c 与 kernel/bpf/syscall.c 中对 BPF_MAP_TYPE_PERF_EVENT_ARRAY 的校验与更新逻辑也与之对应。

读取性能计数器：bpf_perf_event_read 系列

eBPF 程序还可以通过 perf 子系统读取性能数据。辅助函数 bpf_perf_event_read() 和 bpf_perf_event_read_value() 用于读取由 perf_events 管理的硬件性能计数器（如 CPU 周期、缓存未命中等）的值，从而在 eBPF 中把自定义追踪逻辑与底层硬件性能数据结合。例如 tools/perf/util/bpf_skel/bpf_prog_profiler.bpf.c、bperf_leader.bpf.c 中就有对 bpf_perf_event_read_value() 的典型用法。

2. 程序类型协作：BPF_PROG_TYPE_PERF_EVENT

内核定义了专门的 eBPF 程序类型 BPF_PROG_TYPE_PERF_EVENT，允许将 eBPF 程序直接附加到某个 perf 事件上。

• 工作方式：通过 perf_event_open() 创建 perf 事件时，可以指定一个 eBPF 程序作为该事件的溢出处理函数（overflow handler）。当事件触发（例如性能计数器达到采样周期，或 tracepoint 被命中）时，内核会调用该 eBPF 程序。相关逻辑见 kernel/events/core.c 中的 bpf_overflow_handler 以及 perf_event_attach_bpf_prog()；kernel/trace/bpf_trace.c 中则实现了 perf_event_attach_bpf_prog() 的具体附加流程。
• 应用场景：可用于自定义、低开销的采样与分析，例如按 CPU 周期采样时在 eBPF 中记录调用栈或做过滤聚合，比传统 perf 采样更灵活。

3. 用户空间工具整合：从「BPF 事件」到「BPF 脚手架」

在用户空间工具 perf 中，与 eBPF 的集成方式也在演进。

• 过去：perf 曾提供「BPF 事件」机制，允许将编译好的 eBPF 对象文件作为事件加载，但使用和维护成本较高。
• 现在：perf 更多采用 BPF skeleton（libbpf 生成的脚手架）来加载和附加 eBPF 程序。例如 perf trace 使用 tools/perf/util/bpf_skel/augmented_raw_syscalls.bpf.c 等实现系统调用参数增强；off_cpu.bpf.c、bpf_prog_profiler.bpf.c、bperf_leader.bpf.c 等均使用 BPF_MAP_TYPE_PERF_EVENT_ARRAY 与 bpf_perf_event_output() / bpf_perf_event_read_value()，与内核实现一致。

4. 安全与权限统一：CAP_PERFMON

从权限模型看，perf 与 eBPF 的追踪能力由同一 capability 约束。内核在 include/uapi/linux/capability.h 中定义：

/*
 * Allow system performance and observability privileged operations
 * using perf_events, i915_perf and other kernel subsystems
 */
#define CAP_PERFMON    38

同一文件中注释说明：CAP_PERFMON 与 CAP_BPF 共同用于放宽对追踪类 BPF 程序的限制（如指针转整数、部分 speculation 加固的绕过、bpf_probe_read / bpf_trace_printk 等），且「CAP_PERFMON and CAP_BPF are required to load tracing programs」。因此，拥有 CAP_PERFMON 的进程既可以做 perf 采样，也可以在具备 CAP_BPF 等条件下加载用于追踪的 eBPF 程序，两者在权限上统一。

小结：关系总览

下图概括 eBPF 与 perf 在内核中的架构关系、挂载点及数据通道（用户空间工具、系统调用、eBPF 核心与 Map、动态/静态探针、perf_events 子系统及与硬件的交互）：

graph TB
    subgraph Userspace["用户空间 (Userspace)"]
        Tools["perf CLI / bpftrace / BCC"]
        Libs["libbpf / libbcc"]
    end

    subgraph Kernel["内核空间 (Kernel Space)"]
        subgraph Syscall["系统调用层"]
            BPF_Syscall["bpf() 系统调用"]
            Perf_Syscall["perf_event_open() 系统调用"]
        end

        subgraph BPF_Core["eBPF核心虚拟机"]
            Verifier["验证器 (Verifier)"]
            JIT["JIT编译器"]
            Helper["辅助函数 (Helper Funcs)"]
        end

        subgraph BPF_Maps["eBPF Map存储系统"]
            Hash_Map["Hash Map"]
            Array_Map["Array Map"]
            Perf_Array["Perf Event Array"]
            Ring_Buffer["Ring Buffer Map"]
        end

        subgraph BPF_Hooks["eBPF程序挂载点"]
            subgraph Dynamic["动态探针"]
                Kprobe["kprobe (内核函数)"]
                Uprobe["uprobe (用户函数)"]
            end

            subgraph Static["静态探针"]
                Tracepoint["tracepoint (内核静态点)"]
                USDT["USDT (用户静态点)"]
            end

            subgraph Network["网络钩子"]
                XDP["XDP (网卡驱动层)"]
                TC["TC (协议栈)"]
                Socket["Socket Filter"]
            end

            subgraph Perf_Collab["Perf协作层"]
                Perf_Event_Prog["BPF_PROG_TYPE_PERF_EVENT"]
            end
        end

        subgraph Perf_Subsystem["perf_events子系统"]
            Perf_RingBuffer["环形缓冲区 (Ring Buffer)"]
            Perf_PMU["硬件PMU计数器"]
            Perf_Events["软件事件计数"]
            Perf_Tracepoint["tracepoint管理"]
        end
    end

    subgraph Hardware["硬件层"]
        CPU["CPU (含PMU)"]
        NIC["网卡"]
        Memory["内存"]
    end

    Tools --> Libs
    Libs --> BPF_Syscall
    Libs --> Perf_Syscall

    BPF_Syscall --> BPF_Core
    Perf_Syscall --> Perf_Subsystem

    BPF_Core --> BPF_Maps
    BPF_Core --> BPF_Hooks

    BPF_Hooks -.-> Perf_Event_Prog
    Perf_Event_Prog --> Perf_Subsystem

    Perf_Array -.-> Perf_RingBuffer
    Ring_Buffer -.-> Perf_RingBuffer

    Kprobe -.-> |"动态插桩"| Kernel_Funcs["内核任意函数"]
    Uprobe -.-> |"动态插桩"| User_Funcs["用户态任意函数"]
    Tracepoint -.-> |"静态预埋"| Kernel_Points["内核预定义点"]
    USDT -.-> |"静态预埋"| User_Points["用户态预定义点"]

    XDP -.-> |"最早阶段"| NIC
    TC -.-> |"协议栈入口"| Network_Stack["内核协议栈"]

    Perf_PMU --> CPU
    Perf_PMU --> Memory

    BPF_Maps --> |"数据输出"| Libs
    Perf_RingBuffer --> |"性能数据"| Libs

（若站点支持 Mermaid 渲染，上图会显示为流程图；否则会显示为代码块。）

下图从用户空间工具生态视角概括 perf、BCC、bpftrace、libbpf 如何通过 bpf() 系统调用进入内核 eBPF 子系统并最终作用到硬件：

flowchart TD
    subgraph Userspace [用户空间工具生态]
        direction TB
        Tools["perf / 系统工具"] --> |"直接调用"| Syscall
        BCC["BCC工具集<br/>(BPF Compiler Collection)"] --> |"封装复杂逻辑<br/>提供70+现成工具"| Syscall
        bpftrace["bpftrace<br/>(高阶层级语言)"] --> |"基于BCC/libbpf<br/>提供脚本语言"| Syscall
        Libbpf["libbpf<br/>(C库，支持CO-RE)"] --> |"轻量级库<br/>直接控制"| Syscall
    end

    subgraph Kernel [内核空间]
        Syscall["bpf() 系统调用"]
        Syscall --> BPFSubsys["eBPF子系统<br/>(验证器、JIT、辅助函数)"]
        BPFSubsys --> Hooks["挂载点<br/>(kprobe/uprobe/tracepoint/...)"]
    end

    subgraph Hardware [硬件]
        CPU["CPU (含PMU)"]
        Mem["内存"]
        Dev["设备"]
    end

    Hooks --> Hardware

    style BCC fill:#e1f5fe,stroke:#01579b
    style bpftrace fill:#fff3e0,stroke:#e65100
    style Libbpf fill:#f3e5f5,stroke:#4a148c
    style Syscall fill:#e8e8e8,stroke:#666

二、「埋点」思路的演进：预制传感器 vs 可编程探头

「埋点」是两者工作的基础，但埋点方式与后续数据处理思路有本质区别。

• 传统方式（含 perf 的多数功能）：像在内核里预先装好一批固定的、功能单一的传感器，需要什么数据就去读对应传感器的读数。
• eBPF 方式：像提供一种可安全、动态挂载并可编程的探头，可以自己决定测什么、怎么测、以及在内核里做哪些初步处理。

1. 什么是「埋点」？

无论是 perf 还是 eBPF，核心都是在内核（及用户态）关键路径上放置探测点，在事件发生时（系统调用、网络包、函数调用等）采集信息。这些探测点是可观测性的数据源。

2. perf 的埋点思路：预制传感器

perf 主要利用已有的事件源与埋点：

• 硬件事件：利用 CPU 的 PMU（Performance Monitoring Unit） 等硬件计数器，统计周期、缓存未命中、分支预测失败等；perf 负责配置与读取。
• 软件事件：内核维护的统计（如上下文切换、缺页等），perf 直接读取。
• Tracepoints（静态埋点）：内核在关键路径上预先放置的静态探测点（系统调用入口/出口、调度、文件系统等），位置和格式在编译期确定；perf 通过启用这些 tracepoint 采集数据。

perf 的角色更接近「仪表盘操作员」：知道所有预制传感器在哪里、如何读，并以较低开销（尤其是采样）汇总成报告。

3. kprobe 与 uprobe：机制与内核支持

eBPF 的「动态埋点」能力建立在内核的 kprobe 与 uprobe 机制之上。二者允许在不重新编译内核或目标程序的前提下，在运行时把探测点挂在任意内核函数或用户态地址上，下面结合主线内核代码说明其含义与实现要点。

kprobe（Kernel Probe）

kprobe 用于在内核任意函数（或指定偏移）处插入探测。调用方只需提供符号名（如 do_sys_open）或「模块 + 偏移」；内核在注册时通过 kallsyms_lookup_name()（见 kernel/kprobes.c）解析出该符号的地址，无需在编译期固定探测位置。

• 为何是「动态」：探测地址在 register_kprobe() 时才确定。内核维护符号表（kallsyms），可加载模块的符号在模块加载后也可解析；因此可以在不改源码、不重启的前提下，对当前运行内核的任意已导出或可见符号下 probe。
• 内核做了哪些支持：
  • 插桩方式：在探测地址处把第一条指令替换为架构相关的断点指令（如 x86 的 INT3，arm64 的 BRK）。arch_arm_kprobe() / arch_disarm_kprobe() 负责写入/恢复（见 arch/x86/kernel/kprobes/core.c：text_poke(p->addr, &int3, 1) 与恢复 p->opcode）。
  • 原始指令执行：断点命中后，先执行注册的 handler（如 eBPF 程序），再单步执行被替换掉的那条指令。内核在可执行内存中为每条 kprobe 分配「指令槽」（struct kprobe_insn_page，见 kernel/kprobes.c），把原始指令拷贝到槽中执行，避免在运行时代码上直接执行可能受限于可执行页、相对寻址等约束。
  • 优化路径（CONFIG_OPTPROBES）：部分架构还可将「断点 + 单步」优化为「跳转指令」，减少单步与 cache 失效的开销。

相关定义与流程集中在 kernel/kprobes.c（通用逻辑、哈希表 kprobe_table、注册/卸载）、include/linux/kprobes.h（struct kprobe：addr、symbol_name、offset、opcode、ainsn 等），以及各架构的 arch/*/kernel/kprobes/（如 arch_arm_kprobe、指令槽与单步）。

uprobe（User-space Probe）

uprobe 用于在用户态程序的指定虚拟地址处插入探测。通常用「可执行文件 inode + 文件内偏移」或「path + offset」描述位置；同一偏移可对应多个已映射该文件的进程，内核会按 mmap 在各自地址空间写入断点。

• 为何是「动态」：探测的「文件 + 偏移」在注册 uprobe 时指定，无需重新编译或替换用户程序。只要目标进程已将该文件映射为可执行，内核会在其对应 VMA 的虚拟地址上安装断点；新 fork 的进程若映射同一文件，也会在首次访问时通过 MMU notifier 等路径被插入断点（见 kernel/events/uprobes.c 中的 install_breakpoint、set_swbp）。
• 内核做了哪些支持：
  • 插桩方式：在用户空间对应页上写入架构的软断点（如 x86 的 INT3）。set_swbp() 通过 uprobe_write_opcode() 把断点写进目标 VMA；卸载时 set_orig_insn() 恢复原指令（kernel/events/uprobes.c）。
  • 原始指令执行（XOL）：用户态不能像内核那样随意在任意可执行页单步「一条指令」而不影响相邻指令，因此 uprobe 使用 XOL（Execute Out of Line）：为每个被探测的进程维护一块专用可执行映射（struct xol_area，名如 [uprobes]），把「被替换掉的那条指令」拷贝到 XOL 槽中执行，执行完再回到原流程。见 kernel/events/uprobes.c 中的 xol_area、xol_fault、xol_add_vma 以及 arch_uprobe_analyze_insn() 对指令的分析与 ixol 的生成。

uprobe 的消费者通过 struct uprobe_consumer（handler、ret_handler、filter）挂到 struct uprobe 上；eBPF 等会复用这套基础设施，把 BPF 程序作为 consumer 挂到同一 uprobe。

小结：动态的含义与依赖

eBPF 的 kprobe/uprobe 程序类型（如 BPF_PROG_TYPE_KPROBE）即是在上述机制之上，把「断点命中后的处理」换成经 verifier 校验的 BPF 字节码，从而在保持动态性的同时提供可编程、安全的内核/用户态探测能力¹²³。

4. eBPF 的埋点思路：可编程探头

eBPF 在「埋点」上的不同在于动态与可编程：

• 动态埋点（kprobe / uprobe）：若内核或应用没有现成探测点，eBPF 可以在任意内核函数（kprobe）或用户态函数（uprobe） 入口/出口动态挂载探测逻辑，无需改内核源码或重新部署固定 tracepoint（其机制见上一小节）。
• 复用现有埋点：eBPF 也可挂到现有 tracepoint 上；与 perf 不同的是，触发时不仅可以读预定义数据，还可以执行自定义逻辑做过滤、聚合、计算。
• 处理下放：perf 通常把原始或轻度聚合数据经 ring buffer 传到用户空间再由 perf 分析；eBPF 则允许把一部分处理逻辑放在内核（例如只统计延迟 > 100ms 的请求、或在内核里算好直方图），仅把结果或关键数据交给用户空间，减少数据拷贝与上下文切换。

对比总结

因此，两者都建立在「埋点」之上，但 eBPF 的突破在于：在埋点之上增加了动态创建探测点、以及在内核中安全执行自定义处理逻辑的能力，从「读仪表」演进到「可编程探头」。

References

统计概览

对主线内核 rust/ 树使用 cloc、ripgrep（rg）统计的结果如下。

约 75% 的 unsafe 使用配有 // SAFETY: 说明（1 413 / 1 891 ≈ 74.7%），便于审查与维护。

使用场景分类

1. 调用 C 内核 API（FFI / bindings）

通过 bindgen 生成的 C 内核 API 在 Rust 侧一律通过 bindings:: 调用，且这些调用均出现在 unsafe 块或 unsafe fn 内。统计显示 bindings:: 出现约 1062 次，是 unsafe 的一大来源。

典型用法：取得 C 结构体指针、解引用其字段作为参数，再调用 C 函数。例如 PHY 寄存器读写的纯「FFI + 裸指针解引用」：

// rust/kernel/net/phy/reg.rs（节选）
impl Register for C22 {
    fn read(&self, dev: &mut Device) -> Result<u16> {
        let phydev = dev.0.get();
        // SAFETY: `phydev` is pointing to a valid object by the type invariant of `Device`.
        // So it's just an FFI call, open code of `phy_read()` with a valid `phy_device` pointer
        let ret = unsafe {
            bindings::mdiobus_read((*phydev).mdio.bus, (*phydev).mdio.addr, self.0.into())
        };
        to_result(ret)?;
        Ok(ret as u16)
    }

    fn write(&self, dev: &mut Device, val: u16) -> Result {
        let phydev = dev.0.get();
        // SAFETY: ... (同上)
        to_result(unsafe {
            bindings::mdiobus_write((*phydev).mdio.bus, (*phydev).mdio.addr, self.0.into(), val)
        })
    }
}

这里 unsafe 同时覆盖：对 C 指针的解引用（(*phydev).mdio.bus）和 FFI 调用（bindings::mdiobus_read / mdiobus_write）。也就是说，与硬件打交道的驱动路径上，即便逻辑是「读/写寄存器」，在 Rust 侧也会体现为「裸指针 + C API」，因而必然落在 unsafe 内。

2. 硬件与并发语义：volatile 与 READ_ONCE / WRITE_ONCE

与「硬件或外部可写内存」的交互常需要 volatile 或与内核 READ_ONCE/WRITE_ONCE 等价的语义；这类操作在 Rust 中同样必须放在 unsafe 里，且与是否调用 C 无关——纯 Rust 的 MMIO/寄存器访问（如 Embassy 中的实现）也是如此。

（1）文件描述符标志：对应 READ_ONCE

// rust/kernel/fs/file.rs（节选）
pub fn flags(&self) -> u32 {
    // This `read_volatile` is intended to correspond to a READ_ONCE call.
    //
    // SAFETY: The file is valid because the shared reference guarantees a nonzero refcount.
    //
    // FIXME(read_once): Replace with `read_once` when available on the Rust side.
    unsafe { core::ptr::addr_of!((*self.as_ptr()).f_flags).read_volatile() }
}

此处用 read_volatile 表达「可能与其他执行上下文共享的字段」的读，避免编译器优化导致的数据竞争未定义行为，语义上对应 C 侧的 READ_ONCE。

（2）DMA 一致内存：与硬件/用户态竞态

DMA 或与设备/用户态共享的内存，读写同样需要「单次访问不拆、不优化掉」的语义。内核在 dma.rs 中通过 read_volatile / write_volatile 实现，并明确注释其与 READ_ONCE/WRITE_ONCE 的对应关系及适用范围：

// rust/kernel/dma.rs（节选）
pub unsafe fn field_read<F: FromBytes>(&self, field: *const F) -> F {
    // SAFETY:
    // - By the safety requirements field is valid.
    // - Using read_volatile() here is not sound as per the usual rules, the usage here is
    // a special exception with the following notes in place. When dealing with a potential
    // race from a hardware or code outside kernel (e.g. user-space program), we need that
    // read on a valid memory is not UB. Currently read_volatile() is used for this, and the
    // rationale behind is that it should generate the same code as READ_ONCE() which the
    // kernel already relies on to avoid UB on data races. Note that the usage of
    // read_volatile() is limited to this particular case, it cannot be used to prevent
    // the UB caused by racing between two kernel functions nor do they provide atomicity.
    unsafe { field.read_volatile() }
}

pub unsafe fn field_write<F: AsBytes>(&self, field: *mut F, val: F) {
    // SAFETY: ... (与 READ_ONCE 对应地，此处对应 WRITE_ONCE)
    unsafe { field.write_volatile(val) }
}

可见：只要涉及「硬件或内核外部的竞态」，就需要这类 volatile 访问，并因此使用 unsafe，与是否经过 C 代码无关。

3. MMIO / ioremap：资源映射与释放

内存映射 I/O（MMIO）是驱动访问设备寄存器的常见方式。内核 Rust 侧对 ioremap / iounmap 的封装同样在 unsafe 中完成，并配有 SAFETY 注释说明前置条件：

// rust/kernel/io/mem.rs（节选）
fn ioremap(resource: &Resource) -> Result<Self> {
    // ...
    let addr = if resource.flags().contains(io::resource::Flags::IORESOURCE_MEM_NONPOSTED) {
        // SAFETY:
        // - `res_start` and `size` are read from a presumably valid `struct resource`.
        // - `size` is known not to be zero at this point.
        unsafe { bindings::ioremap_np(res_start, size) }
    } else {
        unsafe { bindings::ioremap(res_start, size) }
    };
    // ...
}

impl<const SIZE: usize> Drop for IoMem<SIZE> {
    fn drop(&mut self) {
        // SAFETY: Safe as by the invariant of `Io`.
        unsafe { bindings::iounmap(self.io.addr() as *mut c_void) }
    }
}

这里既有 FFI（调用 C 的 ioremap/iounmap），也有 对「映射得到的地址」所代表的 I/O 内存的访问约定，二者都属于与硬件打交道的边界，因此用 unsafe 是必然的。

4. 裸指针与内存操作

除上述 FFI 与 volatile 外，内核 Rust 中还有大量「裸指针解引用、ptr::read/ptr::write、drop_in_place、addr_of!」等用法，分布在：

• pin-init：未初始化/固定内存的初始化与析构；
• kernel/alloc：自定义分配器、KBox、kvec 等；
• kernel/sync/arc、kernel/list、kernel/rbtree 等：与 C 结构或内核生命周期绑定的共享/链表/树。

这些同样不依赖「是否调 C」：只要涉及未初始化内存、自管理指针或与 C 结构布局的互操作，就需要在 unsafe 中手动维护不变式。

5. 其他：Pin、transmute、Send/Sync

• Pin::new_unchecked、NonNull::new_unchecked、pin-init 的闭包初始化等：用于在保证不移动或初始化顺序的前提下构造对象，约 30+ 处。
• transmute / transmute_copy：与 C 类型或 ABI 的互转、内部表示转换，约 35 处。
• unsafe impl Send / Sync：为内部含裸指针或 FFI 句柄的类型标注可跨线程传递或共享，约 90+ 处。

它们都与「和硬件或 C 边界交互」时的生命周期、布局、并发约定直接相关，是内核 Rust 中 unsafe 的组成部分，而不是「可选的风格问题」。

按子系统的分布（约）

驱动与硬件相关模块（net、block、drm、io、device 等）中 unsafe 密集，与「但凡和硬件扯上关系就需要 unsafe」的直观一致；sync/alloc 则多为并发与内存管理抽象本身的边界。

小结

• 「和硬件扯上关系就要 unsafe」：内核 Rust 的现状与之相符。MMIO（io/mem）、PHY 寄存器（net/phy）、DMA 读写（dma.rs）、以及大量通过 bindings:: 调用的 C 驱动 API，都位于 unsafe 中；驱动/硬件路径几乎必然触及 unsafe。
• 「和是否调用 C 无关」：
  • 调用 C（bindings::）约 1062 处，占 unsafe 比例很高。
  • 但 volatile 访问（file.rs、dma.rs）、裸指针解引用、Pin/初始化、Send/Sync、transmute 等，很多并不依赖「调 C」，而是内核的硬件与内存模型本身就需要在 Rust 中通过 unsafe 表达。
    因此：既有大量「因调 C 而 unsafe」，也有大量「因硬件/并发/内存边界而 unsafe」；与 Embassy 等纯 Rust 驱动/裸机生态一致——与硬件或底层边界打交道的代码，即使用纯 Rust 写，unsafe 仍会集中在这些边界上。

统计基于主线内核 rust/ 树，代码片段取自同一树中的实际文件（见文中路径注释）¹²。

References

1. 谁在管理「等待」？

用户态程序无法直接控制 CPU 的调度，只有内核才有权暂停一个线程（让出 CPU）并在未来某刻恢复它。内核能获得这一能力，依赖两类入口：系统调用（线程主动进入内核，例如调用 futex 后在内核里执行 schedule() 让出 CPU）与定时中断（周期性的时钟中断让内核有机会更新运行时间、设置「需要调度」标志，从而在返回用户态前或下次进入内核时执行 schedule()，实现抢占或时间片轮转）。定时中断路径在 Linux 上的实现大致为：时钟事件驱动 tick_periodic()（传统周期 tick）或 tick_nohz_handler()（高分辨率/动态 tick）→ update_process_times()（kernel/time/timer.c）→ sched_tick()（kernel/sched/core.c）；sched_tick() 的注释写明 “This function gets called by the timer code, with HZ frequency”，在其中更新 runqueue 时钟、调用当前任务所属调度类的 task_tick，并可能调用 resched_curr() 标记需要重新调度，从而在适当时机触发 __schedule() 切换任务²。

• 若锁被占用且等待时间可能较长：线程需要阻塞——主动放弃 CPU、进入睡眠，直到锁被释放。这个「让出 CPU 并睡眠」的动作必须通过内核提供的系统调用来完成，在 Linux 上即 futex 等³⁴。
• 若锁只被短暂占用：线程可以选择自旋，即原地循环检查锁状态，不进入内核；线程一直占着 CPU。这仅适用于多核且持锁时间极短的场景，否则会浪费 CPU。

因此：能「睡下去」和「被唤醒」的锁，一定依赖内核。

2. 关键桥梁：futex (Fast Userspace Mutex)

在现代 Linux 上，几乎所有高性能用户态锁（如 NPTL 的 pthread_mutex、pthread_cond）底层都依赖 futex。其设计哲学正是「大部分时间在用户态解决，必要时才进内核」³⁴。

2.1 无竞争时（Fast Path）

线程尝试加锁时，若锁空闲，只需在用户态用一条原子指令（如 CAS）把锁变量从 0 改为 1。全程无系统调用，极快。

2.2 有竞争时（Slow Path）

1. 用户态：尝试加锁的线程发现锁已被占用，将自身标记为「等待」，然后调用 futex 系统调用进入内核。
2. 内核态：内核把该线程放入与该 futex 对应的等待队列，并调度其他线程运行，当前线程阻塞。
3. 释放与唤醒：持锁线程释放时，在用户态用原子指令把锁变量改回 0，并检查是否有等待者；若有，再调用 futex 通知内核唤醒。
4. 内核响应：内核从等待队列中唤醒被阻塞的线程，该线程得以继续运行并再次尝试获取锁。

因此，futex 本质上是内核提供的「等待队列管理器」，锁的值（0/1）由用户态维护，阻塞与唤醒由内核完成。内核实现见 kernel/futex/：系统调用入口为 SYSCALL_DEFINE6(futex, ...)，根据 op 分发到 futex_wait / futex_wake 等⁴⁵。

3. CPU 层面的锁机制：原子指令与内存序

用户态「无竞争时一条原子指令加锁」依赖 CPU 提供的原子读-改-写（RMW）与内存序保证；否则多核下既无法保证互斥，也无法保证临界区内的写对其他核可见。以下为两种常见架构的要点与权威出处。

3.1 x86：LOCK 前缀与原子性

在 x86 上，LOCK 前缀（opcode F0）可使特定指令在多核下原子执行：目标为内存操作数时，会断言 LOCK# 信号（或等价机制），使该次读-改-写不可被其他 CPU 打断。可加 LOCK 的指令包括 CMPXCHG（比较并交换）、XCHG（与内存交换）、ADD/SUB/INC/DEC 等；XCHG 在目标为内存时即使不加前缀也会具有锁语义。现代 x86（P6 及以后）对已缓存的地址通常采用 cache locking（依赖 MESI 等缓存一致性协议），而非锁总线，从而减少延迟⁶。

LOCK 前缀还带来内存序效果：带 LOCK 的指令与其它 LOCK 指令之间存在全序；普通 load/store 不能与 LOCK 指令重排。因此「加锁」可用带 acquire 语义的原子操作（如 CMPXCHG 成功后相当于 acquire），「解锁」用带 release 语义的写（如原子 store 0），能保证临界区内的修改在解锁后对其它核可见、且其它核的修改在加锁后对本核可见。详见 Intel SDM Vol 3A 第 8 章（Multiple-Processor Management）及 Vol 2A 对 LOCK 的说明⁶。

3.2 ARM：独占加载/存储（LDXR/STXR）与 Exclusive Monitor

ARM 没有像 x86 那样的「单条指令原子 RMW」，而是用 Load-Exclusive / Store-Exclusive 实现：LDXR（Load Exclusive Register）从某地址加载并让该地址被本核的 exclusive monitor 标记；STXR（Store Exclusive Register）仅在该地址仍被本核独占时写入并返回 0，否则写入失败、返回非 0，由软件重试。这样一对 LDXR + STXR 可实现「读-改-写」的原子性，是用户态自旋锁、CAS 等的基础。ARMv8 还提供 LDAXR/STLXR 等带 acquire/release 语义的变种，在实现 mutex 时保证临界区前后的可见性⁷。

Exclusive monitor 是硬件状态：若其它 CPU 在该地址上产生了 store 或其它使独占失效的访问，当前核的 STXR 会失败，从而避免多核同时写。软件需保证在 LDXR 与 STXR 之间不插入会破坏独占性的操作（如显式访问该地址、某些系统寄存器或 cache 维护指令）。详见 ARM 架构参考手册中「Load-Exclusive and Store-Exclusive」与「Synchronization and semaphores」⁷。

3.3 与 futex 的关系

• 无竞争：用户态用上述原子指令（x86 的 CMPXCHG/XCHG，ARM 的 LDXR/STXR 或 LDAXR/STLXR）完成「尝试加锁 / 解锁」，不进入内核，因此极快。
• 有竞争：原子尝试失败后，若选择阻塞，再通过 futex 系统调用进入内核、挂入等待队列。

内核自身在实现 futex 的哈希桶、等待队列时，同样依赖各架构的原子与内存屏障；Linux 内核文档 atomic_t.txt、memory-barriers.txt 对原子 RMW、acquire/release 变种及与锁的配合有统一说明⁷。

4. 为什么不能完全在用户态实现「阻塞」锁？

若完全在用户态实现，当线程拿不到锁时只有两种选择：

1. 自旋（忙等）：一直循环检查。持锁时间一长就会白占 CPU，浪费严重。
2. sleep + 轮询：调用 sleep() 睡一会儿再起来看。延迟不可控（可能刚睡下锁就释放了），且无法做到「锁一释放就立刻被唤醒」。

要实现「锁释放时立刻唤醒」的语义，必须有一个全局的调度者管理线程状态，这个角色只能是操作系统内核。

5. 完全在用户态的锁

有，但适用场景受限：

• 自旋锁：基于原子操作，预期持锁时间仅几条指令时可用。完全不依赖内核，代价是：若锁被长时间持有，CPU 会空转。内核与用户态都常用；用户态自旋锁不涉及 futex。
• 序列锁（seqlock） 等乐观并发：主要在用户态通过内存序与版本号完成，但冲突激烈时可能需重试或退化为等待，仍可能依赖内核。

关于何时用自旋、何时用可睡眠的锁，以及粗粒度锁、持锁做 I/O 对性能的影响，见本博客《为什么「语言速度」是伪命题》#锁的误用与性能¹。

6. 总结

• 上层（用户态）：用原子指令快速尝试获取锁，无竞争时避免任何内核开销。
• 下层（内核）：通过 futex 等原语提供「等待队列 + 调度」，处理阻塞与唤醒。

用户态锁的「快」，是因为无竞争时绕过了内核；它之所以能成为通用的、可阻塞的锁，是因为有竞争时有内核的兜底。

补充阅读：自旋、睡眠与 sleep 时间准确度

自旋就是在浪费 CPU 的循环

自旋（spin）即拿不到锁时不放弃 CPU，在用户态（或内核态）反复执行「读锁变量 → 判断是否可用 → 再读再判断」的循环，直到锁被释放。这段时间里 CPU 一直在跑这条循环，没有做业务逻辑，从系统角度看就是空转、浪费该核的算力。因此自旋只适合「预计很快就能拿到锁」的场景（例如持锁只有几条指令）；否则会长时间白占 CPU。自旋时常配合 PAUSE（x86）或 WFE（ARM）等指令减轻总线竞争，但本质仍是循环等待。

CPU 如何「实现」sleep：没有 sleep 指令，靠调度与上下文切换

CPU 没有「让某条线程 sleep」的指令。「Sleep」是操作系统用调度 + 上下文切换实现的效果：CPU 只是在执行当前被调度到的指令流。

• 线程如何睡过去：线程在用户态执行会阻塞的操作（如 futex(FUTEX_WAIT)、read() 阻塞 fd）时发生系统调用，陷入内核。内核把对应 task 挂到等待队列，状态改为 TASK_INTERRUPTIBLE 等，不再放在 runqueue 上；随后内核调用 schedule()，做上下文切换——把当前线程的寄存器、PC、栈等存到内存，从 runqueue 选另一 task 加载回 CPU 并执行。从这一刻起，「睡着」的线程的指令不再被 CPU 执行。futex 路径上可见 kernel/futex/waitwake.c 中 set_current_state(TASK_INTERRUPTIBLE|TASK_FREEZABLE) 与 futex_do_wait() 内的 schedule()⁵⁸。
• CPU 在做什么：当线程 A sleep 时，A 的上下文保存在内存里，CPU 去执行线程 B 或 idle。没有「sleep」这条指令，只是内核不再把 CPU 分给该线程。
• 易混淆的指令：HLT（x86）/ WFI（ARM）是 idle 任务在「完全没活可干」时用的，让整核等中断，不是「某条线程 sleep」。PAUSE（x86）是自旋等锁时用的，不是 sleep。

Sleep 的时间准确度：定时器到期，由时钟/定时器中断触发唤醒

「睡多久」由内核定时器（timer）到期保证；到期由时钟/定时器中断（或高精度 timer 回调）触发。

• 带时间的 sleep 在内核里：例如 nanosleep(2s)、futex_wait(..., timeout) 时，内核把线程挂到等待队列，并依「当前时间 + 时长」登记一个高精度定时器（hrtimer），到期时间即目标唤醒时间。futex 带超时等待使用 struct hrtimer_sleeper，在 futex_do_wait() 中若传入 timeout 会调用 hrtimer_sleeper_start_expires(timeout, HRTIMER_MODE_ABS)，到期后 hrtimer 回调会间接使该 task 被唤醒⁸。
• 时间到了怎么醒：定时器子系统（如 hrtimer）按到期时间排序，到点由时钟/定时器中断或高精度 timer 中断（及后续 softirq）执行回调；对「sleep 到期」的 timer，回调里通过 wake_up 等把线程从等待队列移回 runqueue，设为可运行。
• 准确度：何时被唤醒（变为 runnable）由 timer 到期与中断路径保证；何时真正再次得到 CPU 还受调度延迟影响（通常为微秒到毫秒级）。高精度定时器（hrtimer）可提供微秒级分辨率；若仅用低分辨率 jiffies，到期检查受 tick 间隔限制。

可参见 kernel/futex/waitwake.c（futex_do_wait、hrtimer_sleeper_start_expires、set_current_state(TASK_INTERRUPTIBLE)、schedule()）及 kernel/sched/core.c（schedule()/__schedule() 的上下文切换）⁵⁸。

扩展阅读（内核与接口）

• futex 系统调用：kernel/futex/syscalls.c 中 SYSCALL_DEFINE6(futex, ...) 与 do_futex()，根据 op（如 FUTEX_WAIT、FUTEX_WAKE）分发到 kernel/futex/waitwake.c 的 futex_wait()、futex_wake()⁴⁵。
• 等待与唤醒逻辑：waitwake.c 中 futex_wait_setup() 将当前任务入队，__futex_wait() 调用 futex_do_wait() 进入调度；futex_wake() 在哈希桶中查找等待者并 wake_up_q()⁵⁹。
• futex 设计：kernel/futex/core.c 文件头注释（Rusty Russell 等）对 Fast Userspace Mutex 的由来与设计有简要说明；LWN 多篇文章介绍其演进与优化³¹⁰。
• CPU 原子与内存序：x86 LOCK 前缀与多核原子见 Intel SDM Vol 2A/Vol 3A；ARM 独占加载/存储见 ARM ARM；Linux 内核 atomic_t.txt、memory-barriers.txt 对原子 RMW 与 acquire/release 的说明⁶⁷。
• 定时中断与调度：kernel/time/timer.c 中 update_process_times() 由时钟中断路径调用，内部调用 sched_tick()；kernel/time/tick-common.c 的 tick_periodic()、kernel/time/tick-sched.c 的 tick_nohz_handler() → tick_sched_handle() 均会调用 update_process_times()；kernel/sched/core.c 中 sched_tick() 以 HZ 频率被 timer 代码调用，负责更新 rq 时钟与 task_tick、必要时 resched_curr()²。
• 自旋、睡眠与 sleep 时间：自旋即占 CPU 的循环等待；sleep 由内核等待队列 + schedule() 实现，无专用 CPU 指令。带超时的 sleep 依赖 hrtimer 到期，由时钟/定时器中断触发唤醒。见 kernel/futex/waitwake.c（futex_do_wait、hrtimer_sleeper_start_expires、TASK_INTERRUPTIBLE、schedule()）⁸。

内核代码片段（与正文对应）

1. futex 系统调用入口与分发（kernel/futex/syscalls.c）

用户态调用 futex(uaddr, op, ...) 时，内核根据 op & FUTEX_CMD_MASK 分发到 futex_wait 或 futex_wake 等；FUTEX_WAIT / FUTEX_WAKE 走 do_futex()⁴⁵。

// 简化自 kernel/futex/syscalls.c（约 84–106 行、160 行）
long do_futex(u32 __user *uaddr, int op, u32 val, ktime_t *timeout,
              u32 __user *uaddr2, u32 val2, u32 val3)
{
    unsigned int flags = futex_to_flags(op);
    int cmd = op & FUTEX_CMD_MASK;
    // ...
    switch (cmd) {
    case FUTEX_WAIT:
    case FUTEX_WAIT_BITSET:
        return futex_wait(uaddr, flags, val, timeout, val3);
    case FUTEX_WAKE:
    case FUTEX_WAKE_BITSET:
        return futex_wake(uaddr, flags, val, val3);
    // ...
    }
}

SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
                const struct __kernel_timespec __user *, utime,
                u32 __user *, uaddr2, u32, val3)
{
    // 超时处理等 ...
    return do_futex(uaddr, op, val, tp, uaddr2, (unsigned long)utime, val3);
}

2. 等待与唤醒：入队与 schedule（kernel/futex/waitwake.c）

__futex_wait() 通过 futex_wait_setup() 准备并入队，再调用 futex_do_wait() 进入睡眠；futex_wake() 根据 uaddr 算哈希桶，在桶内链表中找到匹配的等待者并唤醒⁵⁹。

// 简化自 kernel/futex/waitwake.c
// __futex_wait()（约 666–687 行）：准备等待、入队、进入 schedule
int __futex_wait(u32 __user *uaddr, unsigned int flags, u32 val,
                 struct hrtimer_sleeper *to, u32 bitset)
{
    struct futex_q q = futex_q_init;
    // ...
    ret = futex_wait_setup(uaddr, val, flags, &q, NULL, current);  /* 入队等 */
    if (ret)
        return ret;
    futex_do_wait(&q, to);   /* 在此 schedule，让出 CPU */
    // ...
}

// futex_wake()（约 155–199 行）：查哈希桶、唤醒 nr_wake 个等待者
int futex_wake(u32 __user *uaddr, unsigned int flags, int nr_wake, u32 bitset)
{
    // get_futex_key, futex_hash 得到 hb (hash bucket)
    spin_lock(&hb->lock);
    plist_for_each_entry_safe(this, next, &hb->chain, list) {
        if (futex_match(&this->key, &key)) {
            this->wake(&wake_q, this);
            if (++ret >= nr_wake)
                break;
        }
    }
    spin_unlock(&hb->lock);
    wake_up_q(&wake_q);   /* 真正唤醒等待线程 */
    return ret;
}

3. core.c 中的设计说明（kernel/futex/core.c）

文件头注释说明 futex 的由来（Rusty Russell 等）、「hashed waitqueues」等设计，与正文「内核管理等待队列」对应⁴。

// kernel/futex/core.c 文件头（约 1–32 行）
/*
 *  Fast Userspace Mutexes (which I call "Futexes!").
 *  (C) Rusty Russell, IBM 2002
 *  ...
 *  Thanks to Ben LaHaise for yelling "hashed waitqueues" loudly enough at me...
 */

References

1. 内存分配方式

栈：近乎零成本

栈上分配只需修改栈指针寄存器。在 x86-64 上，函数序言用 sub rsp, N 预留空间（如 sub rsp, 0x10 即 16 字节），一条 CPU 指令、不涉及内核，成本极低¹²。需要澄清：sub rsp, N 本身不会触发任何异常，只是寄存器算术；触发缺页的是后续对该新栈空间的首次访问（见下节）。

; x86-64 函数序言示例：分配 0x20 字节栈帧
    push    rbp
    mov     rbp, rsp
    sub     rsp, 0x20

堆：系统调用的开销

通过 malloc 申请内存时，若分配器内部池子不足，会通过 brk 或 mmap 等系统调用向内核申请。用户态/内核态切换带来微秒级开销，相比一条 sub rsp 可高出数百倍甚至更多³。

2. 物理内存管理

栈：缺页异常与按需映射

修改指针（sub rsp, N）：只是“账面上的分配”。执行 sub rsp, 0x1000 时，CPU 只做寄存器运算，内核对此一无所知。进程虚拟地址空间中这段新栈区在页表里尚未映射到物理页（或映射到只读零页），只是被“预留”出一个地址范围，成本就是一条指令。

首次访问（例如 mov [rsp-8], rax）：才是真正的“物理分配”。当第一次使用这片新栈空间时：(1) CPU 尝试写入该虚拟地址；(2) MMU 查页表发现该页无有效物理页框，无法完成转换；(3) MMU 触发缺页异常（#PF，x86-64 上为中断 14），CPU 转去执行内核的缺页处理（如 do_page_fault()）；(4) 内核从 CR2 读出故障地址，检查是否在进程合法栈区内（如 mm_struct 的 start_stack 及 ulimit -s 限制），若合法则分配物理页、在页表中建立映射并标为可读写；(5) 返回用户态后，原指令重试，此时已有映射，写入成功。这一过程对开发者透明，且每个页只在首次触及该页时发生一次，即惰性分配（Lazy Allocation）：只为实际使用的栈页分配物理内存，若函数分配了大数组但从未访问，就不会占用物理页²。

读与零页：若首次操作是读，内核可先将该虚拟页映射到全局只读的零页；只有后续发生写时才触发写时拷贝（COW），分配真正的物理页并清零，与匿名堆区的零页机制一致。

主线程栈与线程栈：主线程栈可在合法范围内按需增长（访问新区域触发合法缺页即可）；通过 pthread_create 创建的线程，其栈通常在创建时用 mmap 一次性映射固定大小（如 8MB），虚拟范围固定，不会像主线程那样向低地址方向动态增长，访问未映射区域仍会触发缺页并分配物理页。

需要强调的是：在发生缺页的那一刻，栈和堆走的是同一条内核路径（#PF → 分配物理页 → 建立映射，必要时清零），单看这一次缺页本身，栈并不比堆快。栈的「快」体现在：分配虚拟空间无需系统调用（§1）；缺页通常只在首次触及该页时发生一次，成本被摊薄；一旦物理页已常驻，栈与堆的访问就是普通内存访问，没有差别。

类比：sub rsp, N 像在借书卡（页表）上登记一个新书名（虚拟地址），只是记录；首次访问像第一次去书架上取书——管理员发现书（物理页）还在仓库，于是取书、上架、更新借书卡，你才能拿到；若该地址不在进程合法地址空间内，则相当于”查无此书”，会引发 SIGSEGV 等错误。

内核视角：栈与堆的本质区别是 VMA 生命周期

从内核角度看，并不区分”栈”与”堆”，只区分虚拟内存区域（VMA）的类型和生命周期。理解这一点是理解性能差异的关键。

栈 VMA：进程级生命周期

栈在进程启动时由内核创建（fs/exec.c:setup_arg_pages()），设置 VM_GROWSDOWN 标志，表明这是一个”向下增长”的区域：

// 简化自 fs/exec.c:778
static int setup_arg_pages(struct linux_binprm *bprm, ...) {
    vma = vm_area_alloc(mm);
    vma->vm_start = stack_top - STACK_TOP_MAX;  // 通常 8MB
    vma->vm_end = stack_top;
    vma->vm_flags = VM_STACK_FLAGS | VM_GROWSDOWN;  // 唯一特殊标志
    insert_vm_struct(mm, vma);
    // 关键：只创建 VMA，不分配物理页
    return 0;
}

关键点：

1. VMA 在进程启动时创建，进程退出时销毁（生命周期 = 进程）
2. VM_GROWSDOWN 只是一个标志位，告诉内核这个 VMA 可以向低地址扩展
3. 创建时不分配任何物理页，物理页在首次访问时按需分配
4. 函数调用期间，VMA 始终存在——这就是为什么栈分配不需要系统调用

堆 VMA：两种生命周期

brk 堆（小块分配）：

// 简化自 mm/mmap.c:115
SYSCALL_DEFINE1(brk, unsigned long, brk) {
    // 扩展堆顶，可能扩展已有 VMA 或创建新 VMA
    if (do_brk_flags(&vmi, brkvma, oldbrk, newbrk - oldbrk, 0) < 0)
        goto out;
    mm->brk = brk;  // 更新堆顶指针
    // 关键：也只修改 VMA，不分配物理页（除非 VM_LOCKED）
}

• 生命周期：首次 brk() 时创建，进程退出时销毁（类似栈）
• 无特殊标志：没有 VM_GROWSDOWN，但 VMA 同样持久

mmap 堆（大块分配，通常 ≥128KB）：

// 简化自 mm/mmap.c:337
unsigned long do_mmap(struct file *file, unsigned long addr, ...) {
    vma = vm_area_alloc(mm);
    vma->vm_start = addr;
    vma->vm_end = addr + len;
    vma_link(mm, vma, ...);  // 插入红黑树
    return addr;
}

// munmap 销毁
int do_munmap(...) {
    unmap_page_range(vma, ...);   // 删除页表项
    free_pgtables(...);            // 释放页表
    remove_vma(vma);               // 删除 VMA
}

• 生命周期：每次 mmap() 创建，每次 munmap() 销毁（临时性）
• 无特殊标志：普通匿名映射
• 关键差异：每次 malloc/free 大块时都要创建/销毁 VMA，触发系统调用

缺页处理：栈与堆完全相同

无论是栈、brk 堆还是 mmap 堆，首次访问时都走同一条缺页路径：

// mm/memory.c:5022
static vm_fault_t do_anonymous_page(struct vm_fault *vmf) {
    folio = alloc_anon_folio(vmf);        // 分配物理页
    __folio_mark_uptodate(folio);         // 清零
    entry = folio_mk_pte(folio, ...);
    set_ptes(vma->vm_mm, addr, ...);      // 建立页表映射
    // 内核不关心这是栈还是堆！处理流程完全相同
    return 0;
}

结论：在缺页处理层面，栈和堆没有任何区别。单次缺页的成本相同（~20-50μs），都需要分配物理页、清零、建立页表。

性能差异的真正来源

性能差异不是因为内核对栈和堆的”处理方式”不同，而是：

1. VMA 生命周期不同：栈的 VMA 在进程启动时创建，持续到进程结束；mmap 堆的 VMA 每次 malloc/free 都要创建/销毁
2. 系统调用频率不同：栈分配只需改栈指针（CPU 指令），mmap 堆每次都要 mmap()/munmap() 系统调用
3. 页表持久性不同：栈扩展（expand_stack_locked）只修改 VMA 范围，页表映射保留；munmap 会删除页表，下次 mmap 必须重建

栈的”只增不减”特性与物理页缓存

VMA 层面：内核没有 shrink_stack 函数，栈的虚拟地址范围（vma->vm_start - vma->vm_end）在进程运行期间只增不减，永远保持历史最大值：

// 深度递归扩展栈后
VMA: [0x7FEF7000, 0x7FFFFFFF]  // 16MB

// 递归返回，rsp 上移，但 VMA 不缩小
VMA: [0x7FEF7000, 0x7FFFFFFF]  // 仍是 16MB

物理页层面：更关键的是，函数返回后物理页默认不释放，页表映射保持不变。这是栈性能的核心优势。需要区分两种场景：

场景 1：持续访问新页（栈也会缺页）

深度递归访问新栈区域：
    第 1 层 → 访问虚拟页 A → 缺页 #1
    第 2 层 → 访问虚拟页 B（新页）→ 缺页 #2
    ...
    第 100 层 → 访问虚拟页 Z（新页）→ 缺页 #100

持续访问新页时，栈也会持续缺页

场景 2：重复访问已访问页（栈的优势）

第 1 次深度递归（100 层）：
    触发缺页 × 100 → 分配 100 个物理页 → 建立页表映射
    递归返回 → rsp 上移 → 但页表映射保留
    成本：100 × 30μs = 3ms

第 2-1000 次相同深度递归（100 层）：
    rsp 下移到相同虚拟地址 → 页表已有映射 → 0 次缺页
    成本：0μs  ← 物理页”缓存”在页表中

对比 mmap 堆（相同大小的重复 malloc/free）：
    第 1 次：mmap() → 缺页 × 32 → munmap() 删除页表
    第 2 次：mmap() → 缺页 × 32 → munmap() 删除页表
    ...
    1000 次迭代：1000 × (32 × 30μs) = 960ms

实际应用中，大部分函数调用是相同深度的重复，因此栈表现出显著的性能优势。

内核允许用户态通过 madvise(MADV_DONTNEED) 显式释放栈的物理页（保留 VMA），但默认行为是保留以优化性能。进程退出时，exit_mmap() 才释放所有 VMA 和物理页。

这种”懒惰”策略（VMA 不缩小、物理页不释放）正是栈性能优势的根本来源：对于重复访问的栈区域，首次缺页后物理页常驻在页表中，避免反复的分配-释放-再分配循环；但访问新的更深栈区域时，栈也会缺页。实际应用中函数调用多是相同深度的重复，因此栈表现出显著优势。

堆：mmap 与安全清零

通过 mmap 获取匿名内存时，内核会保证进程看到的是「零填充」：要么在缺页时分配并清零，要么先映射到全局零页，写时再分配（copy-on-write），避免读到其他进程残留数据⁴⁵。Gorman《Understanding the Linux Virtual Memory Manager》Ch4 对用户态区段的描述⁵：

With a process, space is simply reserved in the linear address space by pointing a page table entry to a read-only globally visible page filled with zeros. On writing, a page fault is triggered which results in a new page being allocated, filled with zeros, placed in the page table entry and marked writable.

无论哪种方式都会在首次写时产生分配/清零或 COW 开销。malloc 往往通过 mmap 或 sbrk 拿到大块后再在用户态切分、复用，以摊薄这类成本。

3. 缓存友好性

栈：局部性更好

栈的访问模式是典型的 LIFO，当前活跃的局部变量多集中在栈顶附近，容易落在 CPU 的 L1/L2 缓存中，命中率高。

堆：访问模式更分散

堆上对象由程序显式管理，链表、树等结构容易在地址空间内分散，导致缓存行利用率低、更多访问主存。

4. 从内核到用户态：「批发-零售」链条

结合 sbrk、Slab 和 malloc，可以把内存分配看成一条从内核到 CPU 的链条；栈之所以「快」，是因为它处在链条末端，几乎不经中间层。

4.1 一级批发：内核 Buddy（伙伴系统）

物理内存以页（通常 4KB）为最小单位管理，由伙伴系统负责分配和回收：按 2^order 页块管理，不足时分裂大块、释放时与伙伴合并。粒度较粗，不适合直接满足「几十字节」的小请求⁶⁵。

4.2 二级批发：内核 Slab

Slab 分配器从伙伴系统拿到整页，再切成固定大小的对象并缓存，主要服务内核自身（如 task_struct、inode 等）。对象用完后可留在 Slab 中复用，减少对伙伴系统的调用，并缓解内碎片、提高缓存利用率⁶⁵。

4.3 用户态代理：malloc 与 sbrk

用户程序通过 malloc 获取堆内存。当内部池不足时，malloc 会调用 sbrk 或 mmap：

• sbrk 调整 program break，向内核「圈」出一块新的虚拟地址空间，本身是一次系统调用，成本较高；内核用 mm->brk 与 VMA 管理堆顶⁷⁵。
• malloc 把拿到的大块在用户态切分、合并、复用，承担「零售」角色，带来管理开销和可能的碎片。内存池、arena 等做法正是通过减少对 brk/mmap 的调用次数来降低与内核的交互成本；从系统视角看，这与「用户态与内核态壁垒」、减少系统调用的思路一致，可参见本博客《为什么「语言速度」是伪命题》⁸。

4.4 栈：无中间商的「自家后院」

栈不经过上述任何一层：分配就是改栈指针，无需系统调用；物理页在首次访问时按需分配（§2），LIFO 访问模式又利于缓存。因此处在链条最末端，面向 CPU，成本最低。

4.5 开销大致顺序（从慢到快）

5. 「栈比堆快」的边界

单纯比较「栈和堆谁快」容易误导，因为两者不在同一维度：栈更多是「使用已就绪内存」，堆还涉及「获取」和「管理」。

5.1 分配模式才是关键

若事先在堆上分配好一块内存，再反复读写，其访问速度与栈上同规模数据可以非常接近——此时差异主要在「分配方式」，而非「存储介质」。

// 栈：分配 + 使用
void stack_func(void) {
    int arr[1000];   // 分配：改栈指针
    arr[0] = 42;     // 使用：普通内存访问
}

// 堆：一次性分配，反复使用
static int *heap_arr;

void heap_init(void) {
    heap_arr = malloc(1000 * sizeof(int));  // 仅此一次有系统调用/分配器开销
}

void heap_func(void) {
    heap_arr[0] = 42;   // 使用：与栈上访问同属「已就绪内存」
}

5.2 堆可以模拟栈的分配模式

Arena、pool 等分配器本质是在堆上模拟栈：一次性向系统要一大块，用指针顺序分配，最后整体释放。在这种模式下，堆上的「分配」成本可以接近栈。

5.3 值得关注的维度

栈的「快」是用约束换来的：大小有限、生命周期必须 LIFO。堆的灵活则伴随分配与管理开销。工程上更值得关心的是：在给定场景下，应优先用栈、对象池还是堆。

5.4 缺页路径上栈与堆等价，但缺页频率不同

若只比较「第一次访问某页、触发缺页」的那条路径，栈和堆没有区别：都是 #PF → 内核分配物理页 → 映射（堆上匿名区还可能多一步清零或 COW）。因此在单次缺页场景下，栈并不比堆快（单次成本都是 ~20-50μs）。

「栈比堆快」指的是：

1. 分配虚拟空间的成本：栈几乎为零（改栈指针），堆可能涉及系统调用
2. 缺页发生频率（典型场景）：栈访问新页时也会缺页，但实际应用中多是相同深度的重复调用，物理页默认不释放、页表映射持久保留，因此重复访问 0 次缺页；mmap 堆每次 munmap 删除页表，相同大小的重复分配每次都要重建页表并重新缺页
3. 物理页”缓存”机制：栈在首次访问某深度后，该范围内的物理页常驻页表（除非显式释放）；堆每次 malloc/free 都要释放物理页并删除页表

用数字说明典型差异：1000 次相同深度的栈调用可能只触发 1 次缺页（首次访问该深度），而 1000 次相同大小的 mmap 堆分配会触发 1000 次缺页循环。但若持续访问更深的栈区域（新页），栈也会持续缺页。

5.5 用户态申请堆内存是否一定触发缺页？

不一定。 内核源码可以验证两点：

1. 默认情况：用户态通过 brk/sbrk 或 mmap(MAP_ANONYMOUS)「申请」堆内存时，内核只建立或扩展 VMA（虚拟区间），并不立刻分配物理页。mm/vma.c 中的 do_brk_flags() 仅做 vm_area_alloc、设置区间与 flags、挂入红黑树，没有任何 alloc_pages 或 mm_populate。因此物理页要等到首次访问该区间时由缺页处理程序分配，那时才会触发一次 #PF。

2. 会预填页、从而首次访问不触发缺页的情况：

   • mmap(..., MAP_POPULATE)：mm/mmap.c 里 do_mmap 在成功建立映射后，若 flags 含 MAP_POPULATE（且非 MAP_NONBLOCK），会设置 *populate = len，返回用户态前由 mm_populate(ret, populate) 在内核里把页 fault in，所以用户第一次访问时页已在，不会 #PF。
   • 扩展 brk 且进程曾 mlockall（mm->def_flags & VM_LOCKED）：mm/mmap.c 中 SYSCALL_DEFINE1(brk, ...) 在 do_brk_flags() 成功后若 mm->def_flags & VM_LOCKED，会调用 mm_populate(oldbrk, newbrk - oldbrk)，在 brk 返回前就预填新堆区间的页，用户首次访问同样不会触发缺页。

因此：「申请」堆内存本身通常不触发缺页；缺页发生在首次访问新区间时。 只有在使用 MAP_POPULATE 或 VM_LOCKED 时，内核会在申请路径上预填页，此时首次访问不再触发缺页（代价是 brk/mmap 变慢、可能失败）。

5.6 实验验证：栈增长模式对比

为验证「持续访问新栈页会持续缺页」这一关键观察，在 stack-vs-heap-benchmark 项目中实现了对比实验（src/stack_growth_comparison.c），测试两种栈使用模式的缺页行为。

实验配置：

// 关键：使用 -O0 编译，禁用优化以确保真实的栈分配
gcc -O0 -Wall -Wextra -g -o stack_growth_comparison src/stack_growth_comparison.c

#define PAGES_PER_CALL 4  // 每次调用占用 4 页（16KB）
#define ITERATIONS 100

// 场景 1：固定深度重复调用（页表复用）
void fixed_depth_call(void) {
    char buffer[16384];  // 4 页
    // 访问每个页的首尾字节，确保触发缺页...
}
for (int i = 0; i < 100; i++) {
    fixed_depth_call();  // 每次调用相同栈位置
}

// 场景 2：持续增长递归深度（持续缺页）
void growing_depth_call(int depth) {
    char buffer[16384];  // 每层 4 页
    // 访问每个页...
    if (depth > 0) growing_depth_call(depth - 1);  // 递归到更深
}
growing_depth_call(100);  // 100 层递归

实验结果（在 Docker Alpine Linux 环境中，使用 perf 统计）：

$ perf stat -e page-faults ./stack_growth_comparison

=== 场景 1: 固定深度重复调用 ===
配置: 100 次调用，每次 4 页（16KB）
预期: 第 1 次缺页 4 次，后续 99 次无缺页（页表保留）
执行时间: 0.012 ms
平均每次: 118 ns

=== 场景 2: 持续增长递归深度 ===
配置: 100 层递归，每层 4 页（16KB）
预期: 持续缺页 400 次（每层访问新页）
执行时间: 0.272 ms        ← 慢 23 倍！
平均每层: 2715 ns

Performance counter stats for './stack_growth_comparison':

               424      page-faults    ← 接近预期 400 次（100 层 × 4 页）

       0.000999083 seconds time elapsed

关键发现：

实验验证的核心观察：

1. ✅ 持续访问新栈页会持续缺页：场景 2 产生 424 次缺页，接近理论预期 400 次（100 层 × 4 页/层）。多出的 ~24 次来自程序启动、库初始化及场景 1 的栈分配。

2. ✅ 重复访问已访问区域几乎不缺页：场景 1 重复调用 100 次相同深度函数，仅首次触发约 4 次缺页，后续 99 次调用 0 次缺页。

3. ✅ 性能差异显著：持续缺页（场景 2）比页表复用（场景 1）慢 23 倍（0.272 ms vs 0.012 ms），平均每次 2715 ns vs 118 ns。

4. ✅ 实测单次缺页成本：从时间差计算，单次缺页成本约 (2715 - 118) ns ≈ 2.6 μs，低于内核文档中提到的理论值 20-50 μs，得益于现代内核的优化（TLB 缓存、页预取、批量操作等）。

结论：这个实验完美验证了「栈的快不是因为永远不缺页」这一关键观察：

• 访问新栈页时，栈也会持续缺页（如深度递归）
• 栈的真正优势在于页表持久性：重复访问的区域，页表映射保留，避免像 mmap 堆那样每次 munmap 删除、mmap 重建
• 实际应用中多是相同深度的重复调用（如场景 1），因此栈表现”快”；若应用场景是深度递归（如场景 2），栈的缺页行为与分配相同大小的堆区别不大，性能优势主要体现在无需系统调用（VMA 持久）

总结

1. 同一进程内，栈和堆的「访问」速度无本质差别；差异主要来自分配方式与物理页的建立方式（栈按需缺页，堆常伴随清零或 COW）。
2. 内核不区分”栈”与”堆”，只区分 VMA 的类型和生命周期：栈的特殊性仅是 VM_GROWSDOWN 标志；真正的性能差异来自 VMA 生命周期——栈 VMA 在进程启动时创建、进程退出时销毁（0 次运行时系统调用），mmap 堆 VMA 每次 malloc/free 都要创建/销毁（频繁系统调用）。
3. 栈的”只增不减”与物理页缓存机制：VMA 范围在运行期间只增不减（没有 shrink_stack），更关键的是物理页默认不释放——函数返回后页表映射保持不变，这是性能核心：相同栈深度的重复访问首次缺页后，物理页”缓存”在页表中，后续访问 0 次缺页（但持续访问新的更深栈区域仍会缺页）；mmap 堆每次 munmap 删除页表，相同大小的重复分配每次都要重建页表并重新缺页。实验验证（§5.6）：固定深度重复调用（100 次）vs 持续增长递归（100 层），缺页次数 ~4 vs ~400，性能差异 23 倍（0.012 ms vs 0.272 ms）。
4. 在缺页发生的那一刻，栈与堆走同一条内核路径（do_anonymous_page），单次成本相同（~20-50μs）；栈的快体现在：分配虚拟空间零成本（改栈指针）、VMA 持久（无系统调用）、页表持久（expand_stack 保留映射，避免反复缺页）、LIFO 带来的缓存局部性。
5. 从内核 Buddy → Slab → sbrk/mmap → malloc 到栈，是一条「批发-零售」链；栈在末端、无中间层，分配成本最低。
6. 「栈比堆快」是有用的经验法则，但不是普适真理；工程上更值得关心的是「为什么快」和「在什么情况下快」，再按场景选择栈、池或堆。从选型与系统视角看，「谁快」往往不是唯一维度，I/O、并发与内存同内核的交互方式同样关键，可参见本博客《为什么「语言速度」是伪命题》⁸。

扩展阅读

Intel SDM Vol.3A 第 6 章²

§6.14.2「64-Bit Mode Stack Frame」原文：

In IA-32e mode, the RSP is aligned to a 16-byte boundary before pushing the stack frame. The stack frame itself is aligned on a 16-byte boundary when the interrupt handler is called.

§6.15「Exception and Interrupt Reference」中 Interrupt 14—Page-Fault Exception (#PF)：Exception Class 为 Fault；P=0、权限/写/保留位等触发。SDM 原文：

The exception handler can recover from page-not-present conditions and restart the program or task without any loss of program continuity.

Mel Gorman《Understanding the Linux Virtual Memory Manager》⁵

• Ch4 Process Address Space：mm_struct 中堆与栈的字段（见下内核代码）；用户态零页与写时缺页见正文 §2 引用。
• Ch6 Physical Page Allocation：Binary Buddy、free_area_t（Gorman 书为 2.4/2.6 的 free_list+map）、order 分裂/合并。
• Ch8 Slab Allocator：三目标（硬件缓存、对象缓存、内碎片）、slab coloring、kmem_cache_alloc、slabs_full/partial/free、per-CPU 缓存。

Linux 内核源码（代码片段与文件说明）

1. 栈 VMA 的创建：setup_arg_pages（fs/exec.c）

进程启动时创建栈 VMA，设置 VM_GROWSDOWN 标志，生命周期 = 进程。关键：只创建 VMA，不分配物理页。

// 简化自 fs/exec.c:778
static int setup_arg_pages(struct linux_binprm *bprm, ...) {
    vma = vm_area_alloc(mm);
    vma->vm_start = stack_top - STACK_TOP_MAX;  // 通常 8MB
    vma->vm_end = stack_top;
    vma->vm_flags = VM_STACK_FLAGS | VM_GROWSDOWN;  // 栈的唯一特殊标志
    vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
    insert_vm_struct(mm, vma);
    mm->stack_vm += vma_pages(vma);
    return 0;
}