thread.start() 不触发页表切换（cr3不变），因.net线程共享进程地址空间；其汇编开销集中于栈分配、寄存器初始化及系统调用陷入，页表相关开销实为后续调度时的tlb刷新或pcid更新。
Thread.Start() 本身不直接触发 CPU 页表切换，它在汇编层面的开销主要落在线程创建和上下文初始化阶段，而非页表操作本身。页表切换（即 CR3 寄存器更新）只发生在真正发生线程调度、且新线程属于不同进程（或不同地址空间）时——而 .NET 的 Thread 默认运行在**同一进程内**，共享同一个虚拟地址空间和页表基址（CR3 值不变）。所以关键要区分清楚：不是 Start() 调用导致页表切换，而是后续 OS 调度决策可能引发 TLB 刷新或 ASID/PCID 相关开销。
Start() 在汇编层的真实动作
调用 Thread.Start() 后，.NET 运行时最终会进入本地代码（如 coreclr 中的 Thread::TryEnsureActive），其汇编行为主要包括：
- 分配线程私有堆栈内存（通常 1MB，默认保留+提交部分），这会触发动态内存分配及 VAD（Virtual Address Descriptor）插入，但不改 CR3
- 初始化线程控制块（TCB）、设置初始寄存器上下文（RIP 指向 ThreadStartStub，RSP 指向新栈顶，RCX/RDX 等传参）
- 调用系统 API 如 CreateThread（Windows）或 clone(2)（Linux），此时才真正陷入内核
- 内核中完成 TCB 注册、调度队列入队，并标记线程状态为 READY —— 此刻仍未切换页表
页表切换实际发生的条件与时机
页表切换（CR3 更新）仅在以下情况由内核调度器执行：
- 当前线程与待调度线程属于**不同进程**（即拥有不同 mm_struct / EPROCESS），此时必须加载目标进程的页目录基址
- 在同一进程内跨逻辑核心迁移线程时，若启用 PCID（Process Context ID）或 ASID（ARM），则无需 CR3 写入，但需 TLB shootdown + PCID 绑定更新
- .NET 中绝大多数 Thread 都是托管线程，共属一个 process，因此 Start() 后首次被调度时，CR3 不变，只刷新 TLB 条目（如 invlpg 或完整 TLB flush）
可观测的硬核开销点（非 CR3 切换，但密切相关）
真正构成“硬开销”的环节往往藏在 Start() 后的第一次上下文切换中：
- TLB miss 爆发：新线程首次访问内存时，其工作集尚未载入本核 TLB，引发多次 miss + walk page table（多级页表遍历，最多 4–5 次内存访问）
- PCID/ASID 切换延迟：即使 CR3 不变，内核仍需在 schedule() 中写入 MSR_IA32_PCID（x86-64）或 tcr_el1.ASID（ARM64），该 MSR 写操作本身有微秒级延迟
- 栈指针切换与缓存预热：新栈位于不同 cache line 或 NUMA node，首次 push/pop 触发 cold cache miss，尤其影响 JIT 编译后方法入口的指令预取
- 内核栈切换开销：每次从用户态陷入内核（如 clone 返回、或首次 syscalls），需保存/恢复完整的寄存器上下文 + 切换到内核栈，这部分在汇编中清晰可见（如 x86_64 的 swapgs + movq %rsp, percpu_kernel_sp）
如何验证这些开销？
可在 Linux 下配合 perf 工具抓取真实行为：
- perf record -e 'syscalls:sys_enter_clone,syscalls:sys_exit_clone,mem-loads,dtlb_load_misses.miss_causes_a_walk' -- ./your-dotnet-app
- 反汇编 coreclr 的 Thread::StartThread 查看 call qword ptr [CreateThread@GOT] 前后的寄存器准备逻辑
- 用 objdump -d /proc/
/maps 找到线程栈地址，再用 pahole -C task_struct 查看内核中 thread_struct.cr3 字段是否被修改（同进程下应恒定）
