一台跑着 Linux 的机器你 ssh 上去敲个 topCPU 使用率不到 1%进程列表里没一个在干活风扇都懒得转。但如果你这时候去看中断计数会发现每个核每秒都被硬件叫醒一百次、甚至一千次。叫醒它们的不是网卡、不是磁盘而是那个平时几乎没人提起、却又无处不在的东西——时钟中断。在整个操作系统的骨架里它是唯一一个你不写代码它也一定会来的中断源是调度器的心跳、是时间账本的墨水、是超时逻辑的最后一道保险。这篇文章想聊的是它的发生过程信号从哪块晶振出来、经过什么芯片、以什么形式砸到 CPU 上、内核又是怎么把这个信号变成 jiffies 加一、变成一次抢占判断的。如果你正在啃操作系统原理、准备期末或者面试或者单纯对为什么我的进程会被莫名其妙打断这件事好奇接下来的内容应该能给你一条从硬件到软件的完整链路。文中涉及的内核代码路径以主流 Linux 实现为参照其他内核大同小异思路是通用的。1. 什么都没干的机器为什么每秒被叫醒一百次先把这个看似矛盾的现象解释清楚因为它决定了后面所有设计的动机。操作系统要干三件跟时间有关的事而这三件事都没法靠等某个事件发生来解决。第一件是记账一个进程跑了多久、睡眠了多久、系统时间过了多少这些数字必须有人来推进。第二件是调度如果当前进程是死循环且不主动让出 CPU操作系统必须有办法强行把它拉下来否则一个 while(1) 就能把整台机器锁死。第三件是超时网络重传、sleep、锁等待、定时任务这些都需要一个到点了叫我的机制。你可能会说调度和超时可以用事件驱动啊——网卡来了中断就切进程定时任务用硬件闹钟。问题是事件驱动有个致命缺陷如果一直没有事件系统就没有机会做决策。一个 CPU 密集型的死循环进程不给任何中断的机会它就永远霸占着核。所以操作系统需要人为地制造一个周期性事件把控制权强行从用户代码手里收回来。这个人为制造的周期性事件就是时钟中断。它的本质是一个硬件定时器按固定频率产生脉冲每个脉冲触发一次 CPU 中断CPU 跳进内核里的处理函数内核借这个机会更新记账、检查是否需要抢占、处理到期的定时器然后返回。频率由宏HZ决定HZ100是 10 毫秒一次HZ250是 4 毫秒HZ1000是 1 毫秒。选择 HZ 是个典型的工程取舍没有标准答案HZ 取值单次间隔优点代价10010 ms中断开销最小适合吞吐优先的服务器定时精度差select/poll超时误差大2504 ms折中桌面发行版常见精度和开销都一般10001 ms交互响应好超时精度高每秒 1000 次中断功耗和缓存污染明显很多人第一次看到HZ100会疑惑1 毫秒精度的usleep怎么实现答案是**高精度定时器hrtimer**独立于 tick 存在它挂在时钟事件设备上可以在任意时刻到期不依赖固定节拍。tick 负责粗粒度的心跳hrtimer 负责精确到纳秒的闹钟两者分工明确。这一点后面会专门展开。理解了动机你就能明白为什么时钟中断的处理函数里塞了那么多看起来不相关的事情——jiffies 递增、墙钟时间更新、负载计算、进程时间统计、软中断触发、调度 tick。它不是为某一件事服务的它是操作系统的时间基础设施的触发器。2. 硬件那一半从晶振分频到 CPU 跳进中断向量软件侧的代码再漂亮也得等硬件把电信号送过来。这一节我们从下往上看一个脉冲是怎么走完物理层的。2.1 PIT 与 8254最早的节拍器是怎么分频的在很久以前或者说在虚拟机和嵌入式的一些角落里至今x86 平台靠8254 可编程间隔定时器PIT提供时钟节拍。它的输入时钟是 1.193182 MHz——这个奇怪的数字来自 14.31818 MHz 晶振除以 12而 14.31818 MHz 又跟早期彩色电视的副载波频率有关属于历史遗留。PIT 有三个独立计数器其中counter 0被操作系统用来产生时钟中断。它的工作方式很简单往计数器里装一个初值然后每个输入时钟周期减一减到零就输出一个脉冲如果工作在模式 2rate generator分频器模式它会自动重装初值形成周期信号。那我们要的 100 Hz 怎么算分频系数 1193182 ÷ 100 ≈ 11932。写进 PIT 的代码大概长这样/* 设置 PIT counter 0 为模式 2频率 HZ */ #define PIT_CH0 0x40 #define PIT_CMD 0x43 #define PIT_FREQ 1193182UL static void pit_set_frequency(unsigned int hz) { unsigned int divisor PIT_FREQ / hz; outb(0x36, PIT_CMD); /* counter0, 先低后高, 模式2, 二进制 */ outb(divisor 0xFF, PIT_CH0); /* 低字节 */ outb((divisor 8) 0xFF, PIT_CH0); /* 高字节 */ }注意分频系数最大 65535所以 PIT 最低只能到 1193182 ÷ 65535 ≈ 18.2 Hz。如果你的 HZ 想设得比这还低PIT 就无能为力了。PIT 输出的脉冲接到传统8259A 中断控制器的 IRQ0 上映射到中断向量 0x2032 号。这是为什么你翻老的操作系统教材时钟中断总跟32 号向量绑在一起——那是 IBM PC 兼容机时代定下的规矩后来成了事实标准。PIT 的问题是精度差、只此一份。多核时代每个核都需要自己的节拍一颗 PIT 显然不够分而且它的读取需要 out/in 指令开销大。所以现代硬件上PIT 基本只作为兜底存在。2.2 APIC Timer 与 HPET多核时代的替代方案SMP 架构普及之后本地 APICLocal APIC成了主角。每个 CPU 核里都有一个自己的本地 APIC里面集成了一个APIC Timer。它是 per-CPU 的天生适合多核每个核独立计数、独立触发中断互不干扰。APIC Timer 有三种工作模式Periodic 模式装入初值到点触发中断并自动重装跟 PIT 的模式 2 类似。One-shot 模式只触发一次适合 tickless 场景每次需要时重新编程。TSC-deadline 模式直接指定一个 TSC时间戳计数器值当 TSC 达到该值时触发。这个模式精度最高因为 TSC 是 CPU 内部的高频计数器没有分频误差。APIC Timer 的计数基准来自总线时钟或核心时钟频率不固定所以在初始化时内核需要校准它——通常是拿它跟 PIT 或 HPET 对一下算出每秒多少个计数然后才能换算出想要的间隔对应多少初值。这一步在apic.c里做校准失败会退化到别的方案。另一个角色是HPETHigh Precision Event Timer它提供多个独立的比较器可以同时给不同的消费者用精度也高。但 HPET 的寄存器访问要走内存映射的慢路径读一次动辄几百纳秒所以它更适合当时钟源clocksource而不是高频中断源。内核的选择逻辑通常是中断用 APIC Timer读时间用 TSC兜底用 HPET最后才是 ACPI PM Timer 和 PIT。2.3 中断控制器把信号送到哪条腿上脉冲产生了接下来要送到 CPU。这一段的流程是定时器把信号拉高送到中断控制器老平台是 8259A新平台是 I/O APIC 或直接连本地 APIC。中断控制器根据配置把该中断路由到某个 CPU 核并给出一个中断向量号。CPU 在当前指令执行完之后采样中断引脚读取向量号然后去 IDT 里查表。这里有个容易忽略的细节中断路由到哪个核是可以配的。Linux 用irqbalance或手动写/proc/irq/N/smp_affinity来分配。时钟中断比较特殊现代内核里它由每个核自己的 APIC Timer 产生天然落在本地不需要路由但唤醒用的 broadcast 中断后面讲 tickless 时会说就需要指定一个核来发。还有个概念叫中断优先级与屏蔽。CPU 的 EFLAGS 寄存器里有个 IF 位控制是否响应可屏蔽中断。中断门interrupt gate在进入时会自动清 IF也就是关中断防止同一个中断重入陷阱门trap gate不清。时钟中断走的是中断门所以处理函数执行期间本核不会被新的可屏蔽中断打断——这也是为什么中断处理函数必须尽可能短。3. 从向量号到 C 函数一次时钟中断的软件落地路径硬件把球踢过来了现在是内核接球。这一段路径看起来长但每一层都有明确的分工。3.1 IDT、中断门与栈切换CPU 拿到向量号后第一件事是查IDT中断描述符表。IDT 的每一表项是一个门描述符里面记录了处理函数的段选择子和偏移、门类型、权限等级DPL。时钟中断的门是 DPL0 的中断门普通用户代码无法直接触发它。然后是栈切换。如果中断发生在用户态CPU 会从 TSS 里读出该任务的 RSP0内核栈顶切换到内核栈并依次压入 SS、RSP、RFLAGS、CS、RIP有的还会压错误码。如果中断本来就发生在内核态就用当前栈少压两个寄存器。这个细节很重要它意味着中断处理函数的上下文可能是用户态被打断也可能是内核态被打断regs里的 CS 段选择子能告诉你答案——后面统计 user/system 时间就靠它。入口汇编简化示意大致是common_interrupt: SAVE_ALL /* 保存通用寄存器 */ mov %rsp, %rdi call do_IRQ /* 进入 C 世界 */ jmp ret_from_intrSAVE_ALL把寄存器压栈构造出pt_regs结构这就是 C 函数能看到的中断现场。3.2 do_IRQ 到 irq_desc通用中断子系统的分发do_IRQ()是通用中断子系统的入口。它做的事情可以概括为查号、分发、收尾__visible void do_IRQ(struct pt_regs *regs) { unsigned int irq irq_find_mapping(...); /* 由向量号得到逻辑中断号 */ struct irq_desc *desc irq_to_desc(irq); irq_enter(); /* 进入中断上下文关抢占 */ desc-handle_irq(desc); /* 调用该中断的流控处理函数 */ irq_exit(); /* 退出必要时触发软中断 */ }irq_desc是每个中断号的描述结构里面挂了irqaction链表——也就是用户可见的中断处理函数。多个设备可以共享一个中断号IRQF_SHARED所以handle_irq会遍历链表逐个调用。时钟中断的irqaction就是那个真正干活的函数。在 x86 上本地 APIC Timer 被抽象成一个 per-CPU 的中断它的 handler 通常指向tick_periodic()或它在 tick device 框架下的封装。3.3 时钟中断服务例程到底做了哪几件事终于到正题了。tick_periodic()这个函数看着不起眼但它是整个 tick 机制的心脏。它主要做四类事情static void tick_periodic(int cpu) { if (tick_do_timer_cpu cpu) { write_seqlock(jiffies_lock); do_timer(1); /* jiffies 1更新墙钟算负载 */ write_sequnlock(jiffies_lock); } update_process_times(user_mode(get_irq_regs())); /* 进程时间统计 */ profile_tick(CPU_PROFILING); /* 性能采样 */ }拆开看do_timer(1)把全局 jiffies 加一同时更新墙钟时间wall time。注意tick_do_timer_cpu这个判断——多核系统里只有一个核负责推进全局 jiffies其他核不碰避免锁竞争。这是全局时间只由一个 CPU 推进的经典设计。update_process_times()根据中断发生时是用户态还是内核态给当前进程累加utime或stime。这就是top里%user和%sys的来源之一。run_local_timers()触发TIMER_SOFTIRQ软中断把到期的低精度定时器放到软中断里执行避免在硬中断上下文里做太多事。scheduler_tick()更新调度器的时钟调用当前调度类的task_tick决定要不要标记TIF_NEED_RESCHED。这四件事的顺序不是随便排的。jiffies 必须先更新否则后面所有基于时间的判断都拿着旧数据软中断触发放在统计之后是因为它开销相对大放在最后可以尽快进入软中断处理阶段。一个实操层面的体会如果你用 ftrace 抓tick_periodic的执行时间会发现它在干净的系统上通常只有几百纳秒到一两微秒。但如果它突然变成几十微秒八成是有个定时器回调或者负载计算里出现了长耗时操作这时候就该去查软中断和定时器列表了。4. jiffies、tick 与 hrtimer操作系统的时间账本时钟中断来了之后操作系统需要把节拍翻译成时间。这套翻译体系有几个关键角色。4.1 jiffies 与 HZ 的取舍jiffies是一个无符号长整型每次 tick 加一。它的单位就是一个 tick换算成秒要除以 HZ。unsigned long timeout jiffies 5 * HZ; /* 5 秒后超时 */ if (time_after(jiffies, timeout)) { ... }jiffies有个坑它是无符号数会回绕。32 位系统上HZ1000时大约 49.7 天回绕一次。所以内核提供了time_after、time_before这一组宏它们用有符号差值比较能在回绕时依然正确。直接写if (jiffies timeout)是经典错误在回绕边界上会翻车。HZ的取舍前面提过这里补充一个容易被忽略的成本每个 tick 都是一次完整的中断进出涉及寄存器保存恢复、栈切换、缓存扰动。有实测数据显示在 HZ1000 的机器上跑纯计算任务如果把 HZ 降到 100吞吐能提升几个百分点。这就是为什么很多服务器发行版坚持用较低的 HZ。4.2 tick 设备、broadcast 与 NO_HZ现代内核把产生周期中断的硬件抽象成tick devicestruct tick_device它包装了一个clock_event_device。tick device 有几种工作模式周期性模式periodic按固定间隔产生中断最传统。单次模式oneshot每次编程下一个到期点为 tickless 铺路。NO_HZtickless是省电的关键。它的思路是如果 CPU 进入空闲且下一个定时器事件在很远之后那就干脆把周期 tick 停掉只编程一个到那个事件时刻的 oneshot 中断。这段时间里 CPU 可以进入深度睡眠。但这里有个硬件陷阱CPU 进入深 C-state 时本地 APIC Timer 可能停止工作。这时候就需要一个还在运行的定时器来广播唤醒信号这就是tick broadcast机制。内核指定一个核或用一个不停止的定时器作为广播源负责在必要时把睡着的核叫醒。# 查看当前 tick 设备的模式 cat /sys/devices/system/cpu/cpu0/ticks/* 2/dev/null # 内核参数控制 # nohzoff 关闭 tickless # nohz_full2-3 指定核运行无 tick 模式配合 isolcpus # nmi_watchdog0 关掉 NMI 看门狗避免它干扰 nohz_full做低延迟调优的人对这个很熟nohz_full可以让指定核彻底摆脱周期 tick 干扰但前提是那个核上只跑一个任务并且你得处理好 broadcast 的依赖否则可能出现任务睡下去没人叫醒的诡异延迟。4.3 hrtimer 与定时器轮的分工低精度定时器用时间轮timer wheel组织。Linux 的时间轮是分层的每一层对应不同的时间粒度最近的层精度高、桶多远的层精度低、桶少。这样插入和查找的复杂度都能压到 O(1) 附近。时间轮由TIMER_SOFTIRQ驱动在 tick 里被触发。高精度定时器hrtimer用红黑树组织按到期时间排序。它直接挂在clock_event_device上用 oneshot 模式编程。nanosleep、select/poll的超时、timerfd、以及内核里各种需要微秒级精度的场合都靠它。两者分工的边界是如果你的超时容忍度是毫秒级以上用时间轮如果是微秒级或者要求不依赖 HZ用 hrtimer。实际上内核有些接口会在两者之间自动选择取决于你请求的精度和目标时间距现在有多远——这也是为什么有时候usleep(1)实际睡了 50 微秒那是走了低精度路径的代价。# 直接观察 hrtimer 和 tick 设备状态需要 root 和 debugfs mount -t debugfs none /sys/kernel/debug cat /proc/timer_list | head -505. 时钟中断如何变成一次调度决策前面都是铺垫这一节讲时钟中断最核心的价值它怎么让操作系统抢回CPU。5.1 scheduler_tick 与 CFS 的 vruntime 推进scheduler_tick()在每次时钟中断里被调用它做的事是按调度类分发的void scheduler_tick(void) { struct rq *rq this_rq(); struct task_struct *curr rq-curr; raw_spin_lock(rq-lock); update_rq_clock(rq); curr-sched_class-task_tick(rq, curr, 0); raw_spin_unlock(rq-lock); /* ... 负载均衡相关 ... */ }对 CFS完全公平调度器来说task_tick_fair会走到entity_tick里面做三件事更新当前任务的运行时统计update_curr、更新负载、检查是否需要抢占。update_curr是 CFS 的灵魂。它计算当前任务这次实际跑了多久delta_exec然后按权重换算成虚拟时间增量delta_exec_weighted delta_exec * NICE_0_LOAD / curr-se.load.weight; curr-se.vruntime delta_exec_weighted;翻译成人话权重越大的任务nice 值越低每次 tick 推进的 vruntime 越少于是它可以在红黑树里待更久拿到更多 CPU。这就是公平的实现方式——不是给每个任务相同的时间片而是让它们的 vruntime 尽量拉平。举个例子nice0 的权重是 1024nice5 的权重约 335。同样是 4 毫秒的一个 ticknice0 的任务 vruntime 只涨 4ms × 1024/1024 4ms而 nice5 的任务要涨 4ms × 1024/335 ≈ 12.2ms。所以后者的 vruntime 涨得快很快就被排到红黑树右边轮到别人跑。5.2 抢占时机need_resched 与内核抢占点task_tick判断出应该抢占后不会立刻切走——它只是设置当前任务的TIF_NEED_RESCHED标志位真正的切换发生在抢占点。抢占点分几类从内核态返回用户态时exit_to_user_mode_loop里会检查标志这是最常见的一类。从中断返回时irq_exit之后如果不在中断上下文也会检查。内核抢占点cond_resched()、might_sleep()、以及自旋锁释放等显式位置。前提是内核配置了CONFIG_PREEMPT。这里必须区分三种内核配置面试经常问配置行为适用PREEMPT_NONE内核态不可抢占只能等回到用户态吞吐优先的服务器PREEMPT_VOLUNTARY只在显式抢占点切换折中PREEMPT或PREEMPT_RT几乎任何地方都能抢占低延迟、实时时钟中断本身不会直接触发上下文切换它只是设置标志。这一点很多人搞混以为 tick 一到就立刻切进程其实不是。真正的切换由抢占点主导tick 只负责提醒该切了。有个经典现象一个 CPU 密集型进程在PREEMPT_NONE内核上会影响交互响应因为它可能在内核态里待很久才回到用户态。这也是为什么桌面发行版普遍选PREEMPT或PREEMPT_DYNAMIC。5.3 统计口径user、system、idle、iowait 从哪来update_process_times()里那段user_mode(get_irq_regs())判断直接决定了 CPU 时间的归类if (user_mode(regs)) { account_user_time(tsk, delta); /* - utime */ } else if (in_irq() ...) { account_system_time(tsk, delta, ...); /* - stime */ }所以在时钟中断里中断发生在用户态 → 给进程加utime中断发生在内核态 → 给进程加stimeCPU 当时在跑 idle 任务 → 加idle在等 I/O 且被标记为TASK_UNINTERRUPTIBLE→ 加iowaitiowait的统计口径经常被误解。它不是磁盘忙的时间而是CPU 空闲、同时有任务在等 I/O 的时间。如果磁盘很忙但 CPU 也在跑别的活iowait就不会高。理解了这一点你再看vmstat里的wa列就不会误判了。6. 亲手观察一次时钟中断工具、命令与常见误判光看代码不够过瘾能自己动手看到节拍才算真懂。这一节给几个可以直接抄的命令。6.1 用 /proc/interrupts 和 perf 看到节拍# 看本地定时器中断的计数每个 CPU 一列 grep -i -E timer|LOC /proc/interrupts输出里LOC就是本地 APIC Timer 的中断正常情况下每个核的数字会持续增长。如果某个核增长明显比其他核快可能是中断亲和性或者负载不均。# 统计每秒的中断次数 watch -n1 grep -E LOC|timer /proc/interrupts # 用 perf 统计定时器相关事件 perf stat -a -e irq:softirq_entry -e irq:softirq_exit sleep 5 # 抓一段时间内的定时器事件 perf record -a -e timer:* -- sleep 3 perf report/proc/interrupts的数字含义要小心不同内核版本对LOC的统计口径有差异有的把 IPI处理器间中断也算了进去。看到数字很大不代表有问题要看增速是否稳定。6.2 ftrace 跟一遍 tick 处理路径ftrace 是最直接的工具能把函数调用链完整打出来cd /sys/kernel/debug/tracing echo function current_tracer echo tick_periodic set_ftrace_filter echo 1 tracing_on sleep 1 echo 0 tracing_on cat trace | head -30如果只想抓定时器事件的 tracepoint可以echo 0 tracing_on echo 1 events/timer/enable echo 1 tracing_on sleep 2 echo 0 tracing_on cat trace | head -50能看到timer_start、timer_expire_entry、timer_expire_exit这些事件配合进程名和 CPU 号能清楚看到哪个定时器在哪个核上到期。# 用 trace-cmd 更省事 trace-cmd record -e timer -e irq -e sched_switch sleep 3 trace-cmd report | less6.3 时间漂移与中断丢失的排查思路时钟中断相关的问题里最烦人的两类是时间漂移和中断丢失。排查思路可以按这个顺序走。第一确认时钟源。时间漂移的第一嫌疑是 clocksource 不稳。cat /sys/devices/system/clocksource/clocksource0/current_clocksource cat /sys/devices/system/clocksource/clocksource0/available_clocksource dmesg | grep -i -E clocksource|tsc如果日志里出现TSC unstable或者Switched to clocksource hpet说明 TSC 被判定不可靠系统降级用了 HPET精度会差一些但更稳。虚拟机上尤其常见因为 TSC 可能被宿主机的迁移、频率变化影响。解决办法通常是启用半虚拟化时钟KVM 下是kvm-clock让客户机直接读宿主维护的时间。第二确认 tick 是否正常工作。在 tickless 内核上空闲核的 tick 会停掉这时候/proc/interrupts里某个核的LOC不增长是正常的不是 bug。要验证的话可以跑一个忙循环再看taskset -c 2 sh -c while :; do :; done watch -n1 grep LOC /proc/interrupts被绑定的那个核的计数应该开始增长。第三检查是否有中断被屏蔽太久。如果内核里某段代码长时间关中断比如驱动里的临界区tick 会被推迟表现为延迟抖动。用perf或cyclictest可以量化cyclictest -t1 -p 80 -n -i 10000 -l 10000关注Max那一列。正常系统上最大值通常几十微秒如果动辄几毫秒就该去查关中断时长和nohz_full配置了。第四看看中断有没有挤在一个核上。如果irqbalance没跑或者亲和性被写死了某些中断可能全部压在 CPU0导致那个核的系统时间偏高。检查/proc/irq/*/smp_affinity和/proc/interrupts的分布。一个我自己踩过的坑在一台开了nohz_full的机器上某个核上的任务出现了固定周期的 1 毫秒延迟毛刺。查了半天发现是 broadcast 定时器的唤醒源落在了一个没被isolcpus排除的核上那个核的 tick 没关每毫秒发一次唤醒。最后把 broadcast 的 CPU 也隔离出去才干净。这类问题的教训是tickless 不是没有 tick只是按需 tick任何遗漏的唤醒源都会变成抖动。7. 自己写一个最小实现裸机上的时钟中断如果你想彻底搞明白这条链路最好的办法是在裸机上自己接一次。这里给一个 x86 最小可跑的思路跑在 QEMU 里足够。第一步定义 IDT 表项和加载函数struct idt_entry { uint16_t offset_low; uint16_t selector; uint8_t ist; uint8_t type_attr; /* 0x8E 中断门, DPL0, present */ uint16_t offset_mid; uint32_t offset_high; uint32_t zero; } __attribute__((packed)); struct idt_ptr { uint16_t limit; uint64_t base; } __attribute__((packed)); static struct idt_entry idt[256]; static struct idt_ptr idtp; extern void isr32(void); /* 汇编里定义的入口 */ static void set_gate(int n, void (*handler)(void)) { uint64_t addr (uint64_t)handler; idt[n].offset_low addr 0xFFFF; idt[n].selector 0x08; /* 内核代码段 */ idt[n].ist 0; idt[n].type_attr 0x8E; /* 中断门进入时自动关中断 */ idt[n].offset_mid (addr 16) 0xFFFF; idt[n].offset_high (addr 32) 0xFFFFFFFF; idt[n].zero 0; } static void idt_load(void) { idtp.limit sizeof(idt) - 1; idtp.base (uint64_t)idt; __asm__ volatile (lidt %0 : : m(idtp)); }第二步写 32 号向量的入口汇编保存现场、调用 C 函数、发 EOI、返回.global isr32 isr32: push %rax push %rbx push %rcx push %rdx push %rsi push %rdi push %rbp push %r8 push %r9 push %r10 push %r11 mov %rsp, %rdi call timer_handler /* C 处理函数 */ pop %r11 pop %r10 pop %r9 pop %r8 pop %rbp pop %rdi pop %rsi pop %rdx pop %rcx pop %rbx pop %rax iretq第三步C 处理函数里递增计数并把心跳打印出来volatile uint64_t tick_count; void timer_handler(void *regs) { (void)regs; tick_count; /* 每 100 个 tick 打印一次假设 100Hz */ if (tick_count % 100 0) { vga_print(tick\n); } /* 向 PIC 或 LAPIC 发 EOI否则不会再有下一次中断 */ lapic_eoi(); }关键的三个坑第一次写基本都会踩忘记发 EOI中断控制器在收到结束信号前不会再发同一个中断表现就是只中断一次然后没了。8259A 要写 0x20 端口LAPIC 要写 EOI 寄存器。忘记sti开中断中断门虽然会在进入时关 IF但你在初始化完成后必须显式开中断否则什么中断都进不来。栈没对齐System V ABI 要求调用 C 函数时 16 字节对齐压栈数量算错会直接 triple fault 重启而且没有任何报错信息非常难查。用 QEMU 的-d int参数可以打出中断日志帮助定位。把这个最小版本跑通再回头看tick_periodic你会发现那些看起来复杂的代码路径其实就是这套流程加上了分层抽象、多核协调和性能优化而已。我个人在折腾这些东西的过程中最大的体会是时钟中断的难点从来不在中断本身而在谁在什么时候有资格碰全局时间。单核时代这个问题不存在多核之后就变成了tick_do_timer_cpu这种只让一个核推进全局状态的设计再加上 tickless、broadcast、高精度定时器、虚拟化时钟每引入一层都是为了解决上一层的开销或边界问题。所以真正读懂它靠的不是背函数名而是理解每一步为什么必须存在、去掉它会坏在哪。你在排查时间相关的诡异问题时只要沿着信号从哪来、谁在记账、谁负责唤醒、谁被屏蔽了这四条线走基本都能找到出口。
Linux时钟中断全链路：从硬件定时器到调度决策
一台跑着 Linux 的机器你 ssh 上去敲个 topCPU 使用率不到 1%进程列表里没一个在干活风扇都懒得转。但如果你这时候去看中断计数会发现每个核每秒都被硬件叫醒一百次、甚至一千次。叫醒它们的不是网卡、不是磁盘而是那个平时几乎没人提起、却又无处不在的东西——时钟中断。在整个操作系统的骨架里它是唯一一个你不写代码它也一定会来的中断源是调度器的心跳、是时间账本的墨水、是超时逻辑的最后一道保险。这篇文章想聊的是它的发生过程信号从哪块晶振出来、经过什么芯片、以什么形式砸到 CPU 上、内核又是怎么把这个信号变成 jiffies 加一、变成一次抢占判断的。如果你正在啃操作系统原理、准备期末或者面试或者单纯对为什么我的进程会被莫名其妙打断这件事好奇接下来的内容应该能给你一条从硬件到软件的完整链路。文中涉及的内核代码路径以主流 Linux 实现为参照其他内核大同小异思路是通用的。1. 什么都没干的机器为什么每秒被叫醒一百次先把这个看似矛盾的现象解释清楚因为它决定了后面所有设计的动机。操作系统要干三件跟时间有关的事而这三件事都没法靠等某个事件发生来解决。第一件是记账一个进程跑了多久、睡眠了多久、系统时间过了多少这些数字必须有人来推进。第二件是调度如果当前进程是死循环且不主动让出 CPU操作系统必须有办法强行把它拉下来否则一个 while(1) 就能把整台机器锁死。第三件是超时网络重传、sleep、锁等待、定时任务这些都需要一个到点了叫我的机制。你可能会说调度和超时可以用事件驱动啊——网卡来了中断就切进程定时任务用硬件闹钟。问题是事件驱动有个致命缺陷如果一直没有事件系统就没有机会做决策。一个 CPU 密集型的死循环进程不给任何中断的机会它就永远霸占着核。所以操作系统需要人为地制造一个周期性事件把控制权强行从用户代码手里收回来。这个人为制造的周期性事件就是时钟中断。它的本质是一个硬件定时器按固定频率产生脉冲每个脉冲触发一次 CPU 中断CPU 跳进内核里的处理函数内核借这个机会更新记账、检查是否需要抢占、处理到期的定时器然后返回。频率由宏HZ决定HZ100是 10 毫秒一次HZ250是 4 毫秒HZ1000是 1 毫秒。选择 HZ 是个典型的工程取舍没有标准答案HZ 取值单次间隔优点代价10010 ms中断开销最小适合吞吐优先的服务器定时精度差select/poll超时误差大2504 ms折中桌面发行版常见精度和开销都一般10001 ms交互响应好超时精度高每秒 1000 次中断功耗和缓存污染明显很多人第一次看到HZ100会疑惑1 毫秒精度的usleep怎么实现答案是**高精度定时器hrtimer**独立于 tick 存在它挂在时钟事件设备上可以在任意时刻到期不依赖固定节拍。tick 负责粗粒度的心跳hrtimer 负责精确到纳秒的闹钟两者分工明确。这一点后面会专门展开。理解了动机你就能明白为什么时钟中断的处理函数里塞了那么多看起来不相关的事情——jiffies 递增、墙钟时间更新、负载计算、进程时间统计、软中断触发、调度 tick。它不是为某一件事服务的它是操作系统的时间基础设施的触发器。2. 硬件那一半从晶振分频到 CPU 跳进中断向量软件侧的代码再漂亮也得等硬件把电信号送过来。这一节我们从下往上看一个脉冲是怎么走完物理层的。2.1 PIT 与 8254最早的节拍器是怎么分频的在很久以前或者说在虚拟机和嵌入式的一些角落里至今x86 平台靠8254 可编程间隔定时器PIT提供时钟节拍。它的输入时钟是 1.193182 MHz——这个奇怪的数字来自 14.31818 MHz 晶振除以 12而 14.31818 MHz 又跟早期彩色电视的副载波频率有关属于历史遗留。PIT 有三个独立计数器其中counter 0被操作系统用来产生时钟中断。它的工作方式很简单往计数器里装一个初值然后每个输入时钟周期减一减到零就输出一个脉冲如果工作在模式 2rate generator分频器模式它会自动重装初值形成周期信号。那我们要的 100 Hz 怎么算分频系数 1193182 ÷ 100 ≈ 11932。写进 PIT 的代码大概长这样/* 设置 PIT counter 0 为模式 2频率 HZ */ #define PIT_CH0 0x40 #define PIT_CMD 0x43 #define PIT_FREQ 1193182UL static void pit_set_frequency(unsigned int hz) { unsigned int divisor PIT_FREQ / hz; outb(0x36, PIT_CMD); /* counter0, 先低后高, 模式2, 二进制 */ outb(divisor 0xFF, PIT_CH0); /* 低字节 */ outb((divisor 8) 0xFF, PIT_CH0); /* 高字节 */ }注意分频系数最大 65535所以 PIT 最低只能到 1193182 ÷ 65535 ≈ 18.2 Hz。如果你的 HZ 想设得比这还低PIT 就无能为力了。PIT 输出的脉冲接到传统8259A 中断控制器的 IRQ0 上映射到中断向量 0x2032 号。这是为什么你翻老的操作系统教材时钟中断总跟32 号向量绑在一起——那是 IBM PC 兼容机时代定下的规矩后来成了事实标准。PIT 的问题是精度差、只此一份。多核时代每个核都需要自己的节拍一颗 PIT 显然不够分而且它的读取需要 out/in 指令开销大。所以现代硬件上PIT 基本只作为兜底存在。2.2 APIC Timer 与 HPET多核时代的替代方案SMP 架构普及之后本地 APICLocal APIC成了主角。每个 CPU 核里都有一个自己的本地 APIC里面集成了一个APIC Timer。它是 per-CPU 的天生适合多核每个核独立计数、独立触发中断互不干扰。APIC Timer 有三种工作模式Periodic 模式装入初值到点触发中断并自动重装跟 PIT 的模式 2 类似。One-shot 模式只触发一次适合 tickless 场景每次需要时重新编程。TSC-deadline 模式直接指定一个 TSC时间戳计数器值当 TSC 达到该值时触发。这个模式精度最高因为 TSC 是 CPU 内部的高频计数器没有分频误差。APIC Timer 的计数基准来自总线时钟或核心时钟频率不固定所以在初始化时内核需要校准它——通常是拿它跟 PIT 或 HPET 对一下算出每秒多少个计数然后才能换算出想要的间隔对应多少初值。这一步在apic.c里做校准失败会退化到别的方案。另一个角色是HPETHigh Precision Event Timer它提供多个独立的比较器可以同时给不同的消费者用精度也高。但 HPET 的寄存器访问要走内存映射的慢路径读一次动辄几百纳秒所以它更适合当时钟源clocksource而不是高频中断源。内核的选择逻辑通常是中断用 APIC Timer读时间用 TSC兜底用 HPET最后才是 ACPI PM Timer 和 PIT。2.3 中断控制器把信号送到哪条腿上脉冲产生了接下来要送到 CPU。这一段的流程是定时器把信号拉高送到中断控制器老平台是 8259A新平台是 I/O APIC 或直接连本地 APIC。中断控制器根据配置把该中断路由到某个 CPU 核并给出一个中断向量号。CPU 在当前指令执行完之后采样中断引脚读取向量号然后去 IDT 里查表。这里有个容易忽略的细节中断路由到哪个核是可以配的。Linux 用irqbalance或手动写/proc/irq/N/smp_affinity来分配。时钟中断比较特殊现代内核里它由每个核自己的 APIC Timer 产生天然落在本地不需要路由但唤醒用的 broadcast 中断后面讲 tickless 时会说就需要指定一个核来发。还有个概念叫中断优先级与屏蔽。CPU 的 EFLAGS 寄存器里有个 IF 位控制是否响应可屏蔽中断。中断门interrupt gate在进入时会自动清 IF也就是关中断防止同一个中断重入陷阱门trap gate不清。时钟中断走的是中断门所以处理函数执行期间本核不会被新的可屏蔽中断打断——这也是为什么中断处理函数必须尽可能短。3. 从向量号到 C 函数一次时钟中断的软件落地路径硬件把球踢过来了现在是内核接球。这一段路径看起来长但每一层都有明确的分工。3.1 IDT、中断门与栈切换CPU 拿到向量号后第一件事是查IDT中断描述符表。IDT 的每一表项是一个门描述符里面记录了处理函数的段选择子和偏移、门类型、权限等级DPL。时钟中断的门是 DPL0 的中断门普通用户代码无法直接触发它。然后是栈切换。如果中断发生在用户态CPU 会从 TSS 里读出该任务的 RSP0内核栈顶切换到内核栈并依次压入 SS、RSP、RFLAGS、CS、RIP有的还会压错误码。如果中断本来就发生在内核态就用当前栈少压两个寄存器。这个细节很重要它意味着中断处理函数的上下文可能是用户态被打断也可能是内核态被打断regs里的 CS 段选择子能告诉你答案——后面统计 user/system 时间就靠它。入口汇编简化示意大致是common_interrupt: SAVE_ALL /* 保存通用寄存器 */ mov %rsp, %rdi call do_IRQ /* 进入 C 世界 */ jmp ret_from_intrSAVE_ALL把寄存器压栈构造出pt_regs结构这就是 C 函数能看到的中断现场。3.2 do_IRQ 到 irq_desc通用中断子系统的分发do_IRQ()是通用中断子系统的入口。它做的事情可以概括为查号、分发、收尾__visible void do_IRQ(struct pt_regs *regs) { unsigned int irq irq_find_mapping(...); /* 由向量号得到逻辑中断号 */ struct irq_desc *desc irq_to_desc(irq); irq_enter(); /* 进入中断上下文关抢占 */ desc-handle_irq(desc); /* 调用该中断的流控处理函数 */ irq_exit(); /* 退出必要时触发软中断 */ }irq_desc是每个中断号的描述结构里面挂了irqaction链表——也就是用户可见的中断处理函数。多个设备可以共享一个中断号IRQF_SHARED所以handle_irq会遍历链表逐个调用。时钟中断的irqaction就是那个真正干活的函数。在 x86 上本地 APIC Timer 被抽象成一个 per-CPU 的中断它的 handler 通常指向tick_periodic()或它在 tick device 框架下的封装。3.3 时钟中断服务例程到底做了哪几件事终于到正题了。tick_periodic()这个函数看着不起眼但它是整个 tick 机制的心脏。它主要做四类事情static void tick_periodic(int cpu) { if (tick_do_timer_cpu cpu) { write_seqlock(jiffies_lock); do_timer(1); /* jiffies 1更新墙钟算负载 */ write_sequnlock(jiffies_lock); } update_process_times(user_mode(get_irq_regs())); /* 进程时间统计 */ profile_tick(CPU_PROFILING); /* 性能采样 */ }拆开看do_timer(1)把全局 jiffies 加一同时更新墙钟时间wall time。注意tick_do_timer_cpu这个判断——多核系统里只有一个核负责推进全局 jiffies其他核不碰避免锁竞争。这是全局时间只由一个 CPU 推进的经典设计。update_process_times()根据中断发生时是用户态还是内核态给当前进程累加utime或stime。这就是top里%user和%sys的来源之一。run_local_timers()触发TIMER_SOFTIRQ软中断把到期的低精度定时器放到软中断里执行避免在硬中断上下文里做太多事。scheduler_tick()更新调度器的时钟调用当前调度类的task_tick决定要不要标记TIF_NEED_RESCHED。这四件事的顺序不是随便排的。jiffies 必须先更新否则后面所有基于时间的判断都拿着旧数据软中断触发放在统计之后是因为它开销相对大放在最后可以尽快进入软中断处理阶段。一个实操层面的体会如果你用 ftrace 抓tick_periodic的执行时间会发现它在干净的系统上通常只有几百纳秒到一两微秒。但如果它突然变成几十微秒八成是有个定时器回调或者负载计算里出现了长耗时操作这时候就该去查软中断和定时器列表了。4. jiffies、tick 与 hrtimer操作系统的时间账本时钟中断来了之后操作系统需要把节拍翻译成时间。这套翻译体系有几个关键角色。4.1 jiffies 与 HZ 的取舍jiffies是一个无符号长整型每次 tick 加一。它的单位就是一个 tick换算成秒要除以 HZ。unsigned long timeout jiffies 5 * HZ; /* 5 秒后超时 */ if (time_after(jiffies, timeout)) { ... }jiffies有个坑它是无符号数会回绕。32 位系统上HZ1000时大约 49.7 天回绕一次。所以内核提供了time_after、time_before这一组宏它们用有符号差值比较能在回绕时依然正确。直接写if (jiffies timeout)是经典错误在回绕边界上会翻车。HZ的取舍前面提过这里补充一个容易被忽略的成本每个 tick 都是一次完整的中断进出涉及寄存器保存恢复、栈切换、缓存扰动。有实测数据显示在 HZ1000 的机器上跑纯计算任务如果把 HZ 降到 100吞吐能提升几个百分点。这就是为什么很多服务器发行版坚持用较低的 HZ。4.2 tick 设备、broadcast 与 NO_HZ现代内核把产生周期中断的硬件抽象成tick devicestruct tick_device它包装了一个clock_event_device。tick device 有几种工作模式周期性模式periodic按固定间隔产生中断最传统。单次模式oneshot每次编程下一个到期点为 tickless 铺路。NO_HZtickless是省电的关键。它的思路是如果 CPU 进入空闲且下一个定时器事件在很远之后那就干脆把周期 tick 停掉只编程一个到那个事件时刻的 oneshot 中断。这段时间里 CPU 可以进入深度睡眠。但这里有个硬件陷阱CPU 进入深 C-state 时本地 APIC Timer 可能停止工作。这时候就需要一个还在运行的定时器来广播唤醒信号这就是tick broadcast机制。内核指定一个核或用一个不停止的定时器作为广播源负责在必要时把睡着的核叫醒。# 查看当前 tick 设备的模式 cat /sys/devices/system/cpu/cpu0/ticks/* 2/dev/null # 内核参数控制 # nohzoff 关闭 tickless # nohz_full2-3 指定核运行无 tick 模式配合 isolcpus # nmi_watchdog0 关掉 NMI 看门狗避免它干扰 nohz_full做低延迟调优的人对这个很熟nohz_full可以让指定核彻底摆脱周期 tick 干扰但前提是那个核上只跑一个任务并且你得处理好 broadcast 的依赖否则可能出现任务睡下去没人叫醒的诡异延迟。4.3 hrtimer 与定时器轮的分工低精度定时器用时间轮timer wheel组织。Linux 的时间轮是分层的每一层对应不同的时间粒度最近的层精度高、桶多远的层精度低、桶少。这样插入和查找的复杂度都能压到 O(1) 附近。时间轮由TIMER_SOFTIRQ驱动在 tick 里被触发。高精度定时器hrtimer用红黑树组织按到期时间排序。它直接挂在clock_event_device上用 oneshot 模式编程。nanosleep、select/poll的超时、timerfd、以及内核里各种需要微秒级精度的场合都靠它。两者分工的边界是如果你的超时容忍度是毫秒级以上用时间轮如果是微秒级或者要求不依赖 HZ用 hrtimer。实际上内核有些接口会在两者之间自动选择取决于你请求的精度和目标时间距现在有多远——这也是为什么有时候usleep(1)实际睡了 50 微秒那是走了低精度路径的代价。# 直接观察 hrtimer 和 tick 设备状态需要 root 和 debugfs mount -t debugfs none /sys/kernel/debug cat /proc/timer_list | head -505. 时钟中断如何变成一次调度决策前面都是铺垫这一节讲时钟中断最核心的价值它怎么让操作系统抢回CPU。5.1 scheduler_tick 与 CFS 的 vruntime 推进scheduler_tick()在每次时钟中断里被调用它做的事是按调度类分发的void scheduler_tick(void) { struct rq *rq this_rq(); struct task_struct *curr rq-curr; raw_spin_lock(rq-lock); update_rq_clock(rq); curr-sched_class-task_tick(rq, curr, 0); raw_spin_unlock(rq-lock); /* ... 负载均衡相关 ... */ }对 CFS完全公平调度器来说task_tick_fair会走到entity_tick里面做三件事更新当前任务的运行时统计update_curr、更新负载、检查是否需要抢占。update_curr是 CFS 的灵魂。它计算当前任务这次实际跑了多久delta_exec然后按权重换算成虚拟时间增量delta_exec_weighted delta_exec * NICE_0_LOAD / curr-se.load.weight; curr-se.vruntime delta_exec_weighted;翻译成人话权重越大的任务nice 值越低每次 tick 推进的 vruntime 越少于是它可以在红黑树里待更久拿到更多 CPU。这就是公平的实现方式——不是给每个任务相同的时间片而是让它们的 vruntime 尽量拉平。举个例子nice0 的权重是 1024nice5 的权重约 335。同样是 4 毫秒的一个 ticknice0 的任务 vruntime 只涨 4ms × 1024/1024 4ms而 nice5 的任务要涨 4ms × 1024/335 ≈ 12.2ms。所以后者的 vruntime 涨得快很快就被排到红黑树右边轮到别人跑。5.2 抢占时机need_resched 与内核抢占点task_tick判断出应该抢占后不会立刻切走——它只是设置当前任务的TIF_NEED_RESCHED标志位真正的切换发生在抢占点。抢占点分几类从内核态返回用户态时exit_to_user_mode_loop里会检查标志这是最常见的一类。从中断返回时irq_exit之后如果不在中断上下文也会检查。内核抢占点cond_resched()、might_sleep()、以及自旋锁释放等显式位置。前提是内核配置了CONFIG_PREEMPT。这里必须区分三种内核配置面试经常问配置行为适用PREEMPT_NONE内核态不可抢占只能等回到用户态吞吐优先的服务器PREEMPT_VOLUNTARY只在显式抢占点切换折中PREEMPT或PREEMPT_RT几乎任何地方都能抢占低延迟、实时时钟中断本身不会直接触发上下文切换它只是设置标志。这一点很多人搞混以为 tick 一到就立刻切进程其实不是。真正的切换由抢占点主导tick 只负责提醒该切了。有个经典现象一个 CPU 密集型进程在PREEMPT_NONE内核上会影响交互响应因为它可能在内核态里待很久才回到用户态。这也是为什么桌面发行版普遍选PREEMPT或PREEMPT_DYNAMIC。5.3 统计口径user、system、idle、iowait 从哪来update_process_times()里那段user_mode(get_irq_regs())判断直接决定了 CPU 时间的归类if (user_mode(regs)) { account_user_time(tsk, delta); /* - utime */ } else if (in_irq() ...) { account_system_time(tsk, delta, ...); /* - stime */ }所以在时钟中断里中断发生在用户态 → 给进程加utime中断发生在内核态 → 给进程加stimeCPU 当时在跑 idle 任务 → 加idle在等 I/O 且被标记为TASK_UNINTERRUPTIBLE→ 加iowaitiowait的统计口径经常被误解。它不是磁盘忙的时间而是CPU 空闲、同时有任务在等 I/O 的时间。如果磁盘很忙但 CPU 也在跑别的活iowait就不会高。理解了这一点你再看vmstat里的wa列就不会误判了。6. 亲手观察一次时钟中断工具、命令与常见误判光看代码不够过瘾能自己动手看到节拍才算真懂。这一节给几个可以直接抄的命令。6.1 用 /proc/interrupts 和 perf 看到节拍# 看本地定时器中断的计数每个 CPU 一列 grep -i -E timer|LOC /proc/interrupts输出里LOC就是本地 APIC Timer 的中断正常情况下每个核的数字会持续增长。如果某个核增长明显比其他核快可能是中断亲和性或者负载不均。# 统计每秒的中断次数 watch -n1 grep -E LOC|timer /proc/interrupts # 用 perf 统计定时器相关事件 perf stat -a -e irq:softirq_entry -e irq:softirq_exit sleep 5 # 抓一段时间内的定时器事件 perf record -a -e timer:* -- sleep 3 perf report/proc/interrupts的数字含义要小心不同内核版本对LOC的统计口径有差异有的把 IPI处理器间中断也算了进去。看到数字很大不代表有问题要看增速是否稳定。6.2 ftrace 跟一遍 tick 处理路径ftrace 是最直接的工具能把函数调用链完整打出来cd /sys/kernel/debug/tracing echo function current_tracer echo tick_periodic set_ftrace_filter echo 1 tracing_on sleep 1 echo 0 tracing_on cat trace | head -30如果只想抓定时器事件的 tracepoint可以echo 0 tracing_on echo 1 events/timer/enable echo 1 tracing_on sleep 2 echo 0 tracing_on cat trace | head -50能看到timer_start、timer_expire_entry、timer_expire_exit这些事件配合进程名和 CPU 号能清楚看到哪个定时器在哪个核上到期。# 用 trace-cmd 更省事 trace-cmd record -e timer -e irq -e sched_switch sleep 3 trace-cmd report | less6.3 时间漂移与中断丢失的排查思路时钟中断相关的问题里最烦人的两类是时间漂移和中断丢失。排查思路可以按这个顺序走。第一确认时钟源。时间漂移的第一嫌疑是 clocksource 不稳。cat /sys/devices/system/clocksource/clocksource0/current_clocksource cat /sys/devices/system/clocksource/clocksource0/available_clocksource dmesg | grep -i -E clocksource|tsc如果日志里出现TSC unstable或者Switched to clocksource hpet说明 TSC 被判定不可靠系统降级用了 HPET精度会差一些但更稳。虚拟机上尤其常见因为 TSC 可能被宿主机的迁移、频率变化影响。解决办法通常是启用半虚拟化时钟KVM 下是kvm-clock让客户机直接读宿主维护的时间。第二确认 tick 是否正常工作。在 tickless 内核上空闲核的 tick 会停掉这时候/proc/interrupts里某个核的LOC不增长是正常的不是 bug。要验证的话可以跑一个忙循环再看taskset -c 2 sh -c while :; do :; done watch -n1 grep LOC /proc/interrupts被绑定的那个核的计数应该开始增长。第三检查是否有中断被屏蔽太久。如果内核里某段代码长时间关中断比如驱动里的临界区tick 会被推迟表现为延迟抖动。用perf或cyclictest可以量化cyclictest -t1 -p 80 -n -i 10000 -l 10000关注Max那一列。正常系统上最大值通常几十微秒如果动辄几毫秒就该去查关中断时长和nohz_full配置了。第四看看中断有没有挤在一个核上。如果irqbalance没跑或者亲和性被写死了某些中断可能全部压在 CPU0导致那个核的系统时间偏高。检查/proc/irq/*/smp_affinity和/proc/interrupts的分布。一个我自己踩过的坑在一台开了nohz_full的机器上某个核上的任务出现了固定周期的 1 毫秒延迟毛刺。查了半天发现是 broadcast 定时器的唤醒源落在了一个没被isolcpus排除的核上那个核的 tick 没关每毫秒发一次唤醒。最后把 broadcast 的 CPU 也隔离出去才干净。这类问题的教训是tickless 不是没有 tick只是按需 tick任何遗漏的唤醒源都会变成抖动。7. 自己写一个最小实现裸机上的时钟中断如果你想彻底搞明白这条链路最好的办法是在裸机上自己接一次。这里给一个 x86 最小可跑的思路跑在 QEMU 里足够。第一步定义 IDT 表项和加载函数struct idt_entry { uint16_t offset_low; uint16_t selector; uint8_t ist; uint8_t type_attr; /* 0x8E 中断门, DPL0, present */ uint16_t offset_mid; uint32_t offset_high; uint32_t zero; } __attribute__((packed)); struct idt_ptr { uint16_t limit; uint64_t base; } __attribute__((packed)); static struct idt_entry idt[256]; static struct idt_ptr idtp; extern void isr32(void); /* 汇编里定义的入口 */ static void set_gate(int n, void (*handler)(void)) { uint64_t addr (uint64_t)handler; idt[n].offset_low addr 0xFFFF; idt[n].selector 0x08; /* 内核代码段 */ idt[n].ist 0; idt[n].type_attr 0x8E; /* 中断门进入时自动关中断 */ idt[n].offset_mid (addr 16) 0xFFFF; idt[n].offset_high (addr 32) 0xFFFFFFFF; idt[n].zero 0; } static void idt_load(void) { idtp.limit sizeof(idt) - 1; idtp.base (uint64_t)idt; __asm__ volatile (lidt %0 : : m(idtp)); }第二步写 32 号向量的入口汇编保存现场、调用 C 函数、发 EOI、返回.global isr32 isr32: push %rax push %rbx push %rcx push %rdx push %rsi push %rdi push %rbp push %r8 push %r9 push %r10 push %r11 mov %rsp, %rdi call timer_handler /* C 处理函数 */ pop %r11 pop %r10 pop %r9 pop %r8 pop %rbp pop %rdi pop %rsi pop %rdx pop %rcx pop %rbx pop %rax iretq第三步C 处理函数里递增计数并把心跳打印出来volatile uint64_t tick_count; void timer_handler(void *regs) { (void)regs; tick_count; /* 每 100 个 tick 打印一次假设 100Hz */ if (tick_count % 100 0) { vga_print(tick\n); } /* 向 PIC 或 LAPIC 发 EOI否则不会再有下一次中断 */ lapic_eoi(); }关键的三个坑第一次写基本都会踩忘记发 EOI中断控制器在收到结束信号前不会再发同一个中断表现就是只中断一次然后没了。8259A 要写 0x20 端口LAPIC 要写 EOI 寄存器。忘记sti开中断中断门虽然会在进入时关 IF但你在初始化完成后必须显式开中断否则什么中断都进不来。栈没对齐System V ABI 要求调用 C 函数时 16 字节对齐压栈数量算错会直接 triple fault 重启而且没有任何报错信息非常难查。用 QEMU 的-d int参数可以打出中断日志帮助定位。把这个最小版本跑通再回头看tick_periodic你会发现那些看起来复杂的代码路径其实就是这套流程加上了分层抽象、多核协调和性能优化而已。我个人在折腾这些东西的过程中最大的体会是时钟中断的难点从来不在中断本身而在谁在什么时候有资格碰全局时间。单核时代这个问题不存在多核之后就变成了tick_do_timer_cpu这种只让一个核推进全局状态的设计再加上 tickless、broadcast、高精度定时器、虚拟化时钟每引入一层都是为了解决上一层的开销或边界问题。所以真正读懂它靠的不是背函数名而是理解每一步为什么必须存在、去掉它会坏在哪。你在排查时间相关的诡异问题时只要沿着信号从哪来、谁在记账、谁负责唤醒、谁被屏蔽了这四条线走基本都能找到出口。
