A1 fork：一次调用，两次返回

这一篇只盯一行代码：demo 父进程在 CPU4 上执行 pid = fork();。在它返回之前，内核要造出一个新的 task_struct、伪造一份“从没发生过的”切换现场、给它算好虚拟时间、在 12 个 CPU 里挑一个放进去，并且在那个 CPU 正在睡觉的情况下把它叫醒。我们按执行顺序走一遍，每一步都标出源码行号，并用 X9 上的具体数字推演。

0. 场景设定

1. 全景：12 步

下面按顺序展开。

2. 入口：ARM64 上根本没有 fork 系统调用

先纠正一个常见的误解：ARM64 的系统调用表里没有 fork。arch/arm64/include/asm/unistd.h 只在 CONFIG_COMPAT（32 位兼容）下定义了 __ARCH_WANT_SYS_FORK，原生 64 位只有 clone（220 号）和 clone3（435 号）。glibc 的 fork() 在 ARM64 上实际执行的是：

$ strace -f -e trace=clone,clone3 ./demo 1
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
      child_tidptr=0xffff9a3c10f0) = 1235

有两个细节会在后面用到：

• SIGCHLD 放在 flags 的低 8 位（CSIGNAL），表示子进程退出时给父进程发的信号，A9 会用到它。
• CLONE_CHILD_SETTID：内核要把子进程的 TID 写到子进程自己地址空间里的 child_tidptr。这一步要等子进程第一次运行时，在它自己的上下文里完成（schedule_tail → put_user），A3 会看到这一步。

ARM64 还选了 CONFIG_CLONE_BACKWARDS（arch/arm64/Kconfig:128），所以 clone 的参数顺序是 (flags, newsp, parent_tid, tls, child_tid)，和 x86-64 的 (flags, newsp, parent_tid, child_tid, tls) 不一样。直接用 syscall(SYS_clone, …) 写跨架构代码时容易在这里出错。

进入内核的路径（物理视图）：

EL0: svc #0 (x8 = 220)
 → 异常向量 el0t_64_sync：kernel_entry 0 —— 把 x0-x30、sp_el0、elr_el1、spsr_el1 存进内核栈顶的 pt_regs
                                        —— 从 per-cpu 的 __entry_task 取出 current，写入 sp_el0
 → el0t_64_sync_handler：ESR_EL1.EC == SVC64 → el0_svc(regs)
 → do_el0_svc → invoke_syscall → __arm64_sys_clone → kernel_clone(&args)

这份 pt_regs 很重要：它是父进程“在用户态停下来那一刻”的完整现场。第 5 节 copy_thread 会把它原样复制给子进程，只改掉 x0。

3. dup_task_struct：先整块复制，再逐项修正

// kernel/fork.c:1119（节选）
static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
{
        tsk = alloc_task_struct_node(node);
        err = arch_dup_task_struct(tsk, orig);   // ARM64: 先 fpsimd_preserve_current_state()，再 *dst = *src
        err = alloc_thread_stack_node(tsk, node); // 16KB 内核栈（THREAD_SIZE）
        ...
}

*dst = *src 这一句决定了本篇后半部分的写法：子进程的 se.vruntime、se.avg、prio、sched_class、on_cpu、cpus_mask……全部是父进程此刻的值。所以 sched_fork 的任务不是“初始化”，而是“把不该继承的东西改掉”。

ARM64 的 arch_dup_task_struct（arch/arm64/kernel/process.c:297）在拷贝前多做了一件事：fpsimd_preserve_current_state()。父进程的浮点/SIMD 寄存器此刻可能还只在 CPU 的物理寄存器里（懒保存），没写回 task_struct。不先保存的话，子进程拷到的就是一份过期的 FP 状态。它还会把 sve_state 指针清空，因为 SVE 状态缓冲区是单独分配的，不能让父子共用同一块。

4. sched_fork：调度器第一次介入

// kernel/sched/core.c:4683
int sched_fork(unsigned long clone_flags, struct task_struct *p)
{
        __sched_fork(clone_flags, p);           // ① 清零运行统计
        p->__state = TASK_NEW;                  // ② 谁也别想唤醒它
        p->prio = current->normal_prio;         // ③ 不继承 PI 提升
        uclamp_fork(p);
        if (unlikely(p->sched_reset_on_fork)) { ... }   // ④ reset-on-fork
        if (dl_prio(p->prio))
                return -EAGAIN;                 // ⑤ DEADLINE 任务不能 fork
        if (rt_prio(p->prio))        p->sched_class = &rt_sched_class;   // ⑥ 选调度类
        else if (task_should_scx())  p->sched_class = &ext_sched_class;
        else                         p->sched_class = &fair_sched_class;
        init_entity_runnable_average(&p->se);   // ⑦ PELT 初值
        p->on_cpu = 0;
        init_task_preempt_count(p);             // ⑧ FORK_PREEMPT_COUNT
        ...
}

4.1 ① __sched_fork：把“历史”清零

__sched_fork（kernel/sched/core.c:4445）把所有累计量清零：

4.2 ② TASK_NEW：一个“谁也碰不到”的状态

从这里开始，一直到 wake_up_new_task 之前，子进程都处于 TASK_NEW 状态。这段时间里，子进程已经挂到了 PID 哈希表上，外界是能看到它的。比如另一个进程这时对它 kill -CONT，或者 ptrace 去唤醒它，会发生什么？

try_to_wake_up() 只唤醒状态匹配的任务（TASK_NORMAL 等），TASK_NEW 不在任何唤醒掩码里，所以这些外部唤醒全部无效。这就保证了子进程只会被 wake_up_new_task 放进队列一次，不会出现“还没初始化完就被别人塞进运行队列”的情况。

4.3 ③ 不继承 PI 提升：一个 demo 里真实可能发生的例子

4.4 ④⑤⑥ 策略与调度类：五个父进程，五种结果

$ sudo chrt -d --sched-runtime 1000000 --sched-deadline 10000000 --sched-period 10000000 0 \
       bash -c 'ls >/dev/null; true'
bash: fork: retry: Resource temporarily unavailable
...
bash: fork: Resource temporarily unavailable

4.5 ⑦ PELT 初值：负载满、利用率 0

// kernel/sched/fair.c:1055
void init_entity_runnable_average(struct sched_entity *se)
{
        memset(sa, 0, sizeof(*sa));
        if (entity_is_task(se))
                sa->load_avg = scale_load_down(se->load.weight);   // nice 0 → 1024
}

这里有一个有意设计的不对称：

• load_avg 设成满值（1024）：负载均衡把新任务当作“重”任务来看待，宁可高估。否则一连串 fork 出来的任务，每个都显得“很轻”，负载均衡会把它们全部堆在同一个 CPU 上。
• util_avg 先设成 0：真正的初值要等到入队时，由 post_init_entity_util_avg 根据目标 CPU 的情况来推算（见 7.2 节）。

这个“先 0 后推算”的时间差，正是第 7 节里 C 会被放到小核的根本原因。

4.6 ⑧ FORK_PREEMPT_COUNT：给 A3 埋的伏笔

init_task_preempt_count(p) 把子进程的 preempt_count 设为 FORK_PREEMPT_COUNT = 2 × PREEMPT_DISABLE_OFFSET + PREEMPT_ENABLED（include/linux/preempt.h:76）。为什么新任务要带着“抢占已关两层”出生？因为它第一次运行时，是从 __schedule() 的中间“醒来”的，那里 rq 锁还没释放、抢占还关着。A3 的 图 A3-4 会把这笔账一项项对上。

5. copy_mm 与 copy_thread：决定“将来切换时要换什么”

5.1 copy_mm：进程与线程的分水岭

5.2 copy_thread：伪造一份“刚被切走”的现场

arch/arm64/kernel/process.c:352 做了三件事：

*childregs = *current_pt_regs();        // 父进程 svc 时保存的现场，整份复制
childregs->regs[0] = 0;                  // ← 子进程的 fork() 返回值就是这么来的
...
p->thread.cpu_context.pc = (unsigned long)ret_from_fork;
p->thread.cpu_context.sp = (unsigned long)childregs;

这是整个 fork 里最巧妙的一步。为了理解它，先记住 A3 会详细讲的一个事实：cpu_switch_to 切换到任何任务时，都是从 next->thread.cpu_context 里恢复 x19-x29/sp/lr，然后执行 ret。

• 对于一个跑过的任务，cpu_context 是它上一次被切走时保存的，ret 会回到它当时在 __switch_to 里的位置。
• 对于子进程，copy_thread 手工写好了一份：sp 指向内核栈顶的 pt_regs，lr（cpu_context.pc）指向 ret_from_fork。第一次被切入时，ret 就会跳到 ret_from_fork，接着一路返回到用户态。

所以调度器不需要知道谁是新任务，同一套 context_switch 代码对新老任务都适用。这是一种很常见的“伪造栈帧”技巧，x86、RISC-V 也都这么做。

还有两个 ARM64 特有的点：

• x19/x20 是“内核线程标记”。 用户进程的 x19 = 0；kthread_create 创建的内核线程 x19 = fn、x20 = fn_arg。ret_from_fork 用 cbz x19 判断走哪条路（arch/arm64/kernel/entry.S:858）。
• TLS。 *task_user_tls(p) = read_sysreg(tpidr_el0) 直接读当前的 TPIDR_EL0，因为用户态可能改过这个寄存器，而 task_struct 里保存的值还没来得及更新。如果带了 CLONE_SETTLS（pthread_create 会带），就改用参数里传进来的 tls。

6. sched_cgroup_fork：先“临时”放在当前 CPU

// kernel/sched/core.c:4757
raw_spin_lock_irqsave(&p->pi_lock, flags);
tg = container_of(kargs->cset->subsys[cpu_cgrp_id], struct task_group, css);
p->sched_task_group = autogroup_task_group(p, tg);
__set_task_cpu(p, smp_processor_id());    // ← 先放在 CPU4（父进程所在 CPU）
if (p->sched_class->task_fork)
        p->sched_class->task_fork(p);      // fair: set_task_max_allowed_capacity(p)
raw_spin_unlock_irqrestore(&p->pi_lock, flags);

• __set_task_cpu(p, 4) 只是个占位。 这时还没有真正选核，但 task_cpu(p) 必须有一个合法值，否则后面的代码（比如 cgroup 迁移）没法计算 task_rq(p)。真正的选核在第 7 节。
• task_fork_fair 在 6.12 里只剩一件事：计算 p->max_allowed_capacity，也就是在 cpus_ptr 允许的 CPU 中，最大的那个 capacity。

7. wake_up_new_task：选核、入队、叫醒

// kernel/sched/core.c:4822
void wake_up_new_task(struct task_struct *p)
{
        int wake_flags = WF_FORK;
        raw_spin_lock_irqsave(&p->pi_lock, rf.flags);
        WRITE_ONCE(p->__state, TASK_RUNNING);                              // 7.0
        p->recent_used_cpu = task_cpu(p);
        __set_task_cpu(p, select_task_rq(p, task_cpu(p), &wake_flags));    // 7.1 选核
        rq = __task_rq_lock(p, &rf);
        update_rq_clock(rq);
        post_init_entity_util_avg(p);                                      // 7.2 推算 util
        activate_task(rq, p, ENQUEUE_NOCLOCK | ENQUEUE_INITIAL);           // 7.3 入队
        trace_sched_wakeup_new(p);
        wakeup_preempt(rq, p, wake_flags);                                 // 7.4 要不要抢占
        ...
        task_rq_unlock(rq, p, &rf);
}

注意这里的顺序：先选核（7.1），再推算 util（7.2）。这个顺序直接决定了下面的结果。

7.1 选核：为什么是小核 CPU2

select_task_rq(p, 4, WF_FORK) → select_task_rq_fair()（kernel/sched/fair.c:8687）。由于带的是 WF_FORK，而不是 WF_TTWU：

1. 跳过 EAS：find_energy_efficient_cpu 只在 WF_TTWU 分支里调用，fork 不走 EAS。
2. 跳过 wake_affine：want_affine 同样只在 WF_TTWU 下计算。
3. 沿调度域从下往上找，第一个带 SD_BALANCE_FORK 标志的域是 MC（X9 只有这一层），于是进入慢路径 sched_balance_find_dst_cpu()（kernel/sched/fair.c:7600）。

慢路径在 MC 域的 12 个单 CPU 组里，调用 sched_balance_find_dst_group()（kernel/sched/fair.c:10852）：

为什么会挑到一个小核？ 关键在于这一刻子进程的 util_avg = 0（4.5 节）。update_sg_wakeup_stats 里对每个 CPU 调用的 task_fits_cpu(p, cpu)，在 util 为 0 时恒为真，所以不会产生 group_misfit_task 这种分类，capacity 大小完全不参与比较。fork 选核只看“哪里空”，不看“哪里强”。

7.2 推算初始 util：C 在 CPU2 上“一出生”就有 134

选定 CPU2 之后，post_init_entity_util_avg()（kernel/sched/fair.c:1100）根据目标 CPU 的情况推算初值：

long cpu_scale = arch_scale_cpu_capacity(cpu_of(rq_of(cfs_rq)));   // CPU2: 280
long cap = (long)(cpu_scale - cfs_rq->avg.util_avg) / 2;           // (280 - 12) / 2 = 134
if (cfs_rq->avg.util_avg != 0) {
        sa->util_avg  = cfs_rq->avg.util_avg * se_weight(se);      // 12 × 1024
        sa->util_avg /= (cfs_rq->avg.load_avg + 1);                // ÷ (10 + 1) ≈ 1117
        if (sa->util_avg > cap)
                sa->util_avg = cap;                                 // → 134
}

第 n 个任务的 util_avg: 512, 256, 128,  64,  32, ...
cfs_rq 的 util_avg:     512, 768, 896, 960, 992, ...

7.3 入队与放置：vruntime 和 deadline 的初值

activate_task → enqueue_task_fair → enqueue_entity → place_entity(cfs_rq, se, ENQUEUE_INITIAL)（kernel/sched/fair.c:5291）：

u64 vslice, vruntime = avg_vruntime(cfs_rq);      // V：队列的加权平均虚拟时间
if (!se->custom_slice)
        se->slice = sysctl_sched_base_slice;      // 2.8ms
vslice = calc_delta_fair(se->slice, se);          // nice 0：vslice = slice = 2.8ms
if (sched_feat(PLACE_LAG) && cfs_rq->nr_running) {
        lag = se->vlag;                            // 新任务 vlag = 0 → lag = 0
        ...
}
se->vruntime = vruntime - lag;                    // = V
if (sched_feat(PLACE_DEADLINE_INITIAL) && (flags & ENQUEUE_INITIAL))
        vslice /= 2;                               // 新任务只给半个 slice 的 deadline
se->deadline = se->vruntime + vslice;             // = V + 1.4ms

把 EEVDF 的规则放到这两个例子里来看（B3 会完整展开 EEVDF）：

• eligible：v ≤ V 的任务才有资格被选中（它“没多拿”）。
• 在所有 eligible 的任务里，选 deadline 最早的那个。

为什么新任务的 deadline 只给半个 slice？ 源码注释的解释是：“新加入竞争时，已有任务平均来说正处在它们时间片的一半，所以新任务也从半个时间片起步。”这让新任务比较快就能轮到，但又不会像 v 设得更小那样“插队插到最前面”。

7.4 wakeup_preempt：要不要叫醒 CPU2？

// kernel/sched/core.c:2140
void wakeup_preempt(struct rq *rq, struct task_struct *p, int flags)
{
        if (p->sched_class == rq->curr->sched_class)
                rq->curr->sched_class->wakeup_preempt(rq, p, flags);   // 同类：交给 fair 判断
        else if (sched_class_above(p->sched_class, rq->curr->sched_class))
                resched_curr(rq);                                      // 更高的类：直接抢
}

CPU2 当前运行的是 idle 任务（swapper/2，属于 idle 类）。fair 类比 idle 类高，所以直接调用 resched_curr(rq2)。

• 如果 C 落在例 b 的 CPU4 上，就会走 check_preempt_wakeup_fair（kernel/sched/fair.c:8862）：NEXT_BUDDY 默认关闭，并且对 WF_FORK 明确排除；之后调用 pick_eevdf，因为 slice 保护返回的是 P，所以不抢占。
• fork 的特殊之处：普通唤醒如果开了 NEXT_BUDDY，会把被唤醒者设为“下一个优先选”；代码里用 !(wake_flags & WF_FORK) 明确把 fork 排除在外，新出生的子进程不会因此被照顾。

8. 进程视图：两把锁、一个远程 CPU、一次 IPI

从并发的角度看，第 7 节发生在 CPU4 上，但它修改的是 CPU2 的运行队列：

1. 锁的顺序是 p->pi_lock → rq->lock，全内核统一。pi_lock 保护任务的“放哪”（cpus_ptr、task_cpu、__state），rq->lock 保护“队列里有谁”。先锁任务、再锁队列，C1 会解释为什么不能反过来。
2. CPU4 远程拿 CPU2 的 rq 锁：__task_rq_lock(p) 根据 task_cpu(p) = 2 锁住 cpu_rq(2)->__lock。持锁期间 CPU2 对此毫不知情，它还在 wfi 里睡着。
3. 怎么叫醒 CPU2：resched_curr(rq2)（kernel/sched/core.c:1083）先给 CPU2 的当前任务（idle）设置 TIF_NEED_RESCHED。有些架构的 idle 是轮询 need_resched 的（设置了 TIF_POLLING_NRFLAG），只要写这个标志位就能叫醒；ARM64 没有定义 TIF_POLLING_NRFLAG，idle 是真的执行 wfi 停在那里，所以必须发 IPI：smp_send_reschedule(2) → arch_smp_send_reschedule → GIC 发出 SGI（IPI_RESCHEDULE）（arch/arm64/kernel/smp.c:1099）。
4. CPU2 收到 SGI → WFI 退出 → do_handle_IPI → scheduler_ipi() → preempt_fold_need_resched()。之后回到 do_idle 的循环，发现 need_resched() 为真，于是退出循环，调用 schedule_idle()。这是下一篇 A3 的起点。

9. 父进程这一边：返回 PID 之前的几个细节

回到 kernel_clone（kernel/fork.c:2782）：

p = copy_process(NULL, trace, NUMA_NO_NODE, args);
trace_sched_process_fork(current, p);      // 必须在唤醒之前：唤醒之后 p 可能已经跑完并退出了
pid = get_task_pid(p, PIDTYPE_PID);        // 先拿一个引用
nr = pid_vnr(pid);
wake_up_new_task(p);                       // 从这一刻起，C 可能已经在 CPU2 上运行
if (clone_flags & CLONE_VFORK)
        wait_for_vfork_done(p, &vfork);    // vfork：父进程睡眠，直到子进程 exec 或 exit
put_pid(pid);
return nr;

10. 动手实验

10.1 用 tracepoint 看 fork 与选核

sudo trace-cmd record -e sched:sched_process_fork -e sched:sched_wakeup_new \
                      -e sched:sched_switch ./demo 1
sudo trace-cmd report | grep -E "fork|wakeup_new|==> next_comm=demo" | head

期望看到类似下面的输出（X9，数字为示意）：

demo-1234 [004] 100.200011: sched_process_fork: comm=demo pid=1234 child_comm=demo child_pid=1235
demo-1234 [004] 100.200015: sched_wakeup_new:   comm=demo pid=1235 prio=120 target_cpu=002
<idle>-0  [002] 100.200019: sched_switch:       prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=demo next_pid=1235 next_prio=120

• sched_wakeup_new 是在 CPU4 上打出来的（方括号里是 004），target_cpu=002 就是 7.1 节选核的结果。
• 4 微秒之后，CPU2 上出现了 swapper/2 ==> demo，这是 A3 讲的那次切换。这 4 微秒包括：IPI 投递、WFI 退出，以及可能的 idle 状态退出延迟。如果 CPU2 当时处在更深的 PSCI 睡眠状态，这个数会大很多。A6 会专门讨论这一点。

10.2 用 bpftrace 看初始 util 与 vruntime

sudo bpftrace -e '
tracepoint:sched:sched_wakeup_new {
    printf("child %d -> cpu%d\n", args->pid, args->target_cpu);
}
kprobe:place_entity {
    $se = (struct sched_entity *)arg1;
    printf("  place: util=%lu vlag=%lld flags=0x%x\n", $se->avg.util_avg, $se->vlag, arg2);
}'

10.3 验证“小核出生，大核长大”

子进程的主线程大部分时间在 sleep()，util 不会涨。真正一直在计算的是 worker 线程，它由 pthread_create → clone 创建，同样走了一遍本篇的流程：

./demo 3 &
sleep 0.05
W=$(ps -eLo tid,comm | awk '$2=="worker"{print $1}')
grep -E "se.avg.util_avg|nr_migrations" /proc/$W/sched   # 刚出生：util 是推算出的初值，nr_migrations = 0
sleep 1
grep -E "se.avg.util_avg|nr_migrations" /proc/$W/sched   # 如果出生在小核：util 涨到接近 280 后会被搬走，nr_migrations ≥ 1
taskset -pc $W; ps -o psr= -L -p $(pgrep -n demo)          # 看它现在在哪个 CPU

11. 小结

12. 自测