interrupt
[TOC] include/linux/interrupt.hor_softirq_pending 软中断待处理状态12345678DEFINE_PER_CPU_ALIGNED(irq_cpustat_t, irq_stat);EXPORT_PER_CPU_SYMBOL(irq_stat);#define local_softirq_pending_ref irq_stat.__softirq_pending#define local_softirq_pending() (__this_cpu_read(local_softirq_pending_ref))#define set_softirq_pending(x) (__this_cpu_write(local_softirq_pending_ref, (x)))#define or_softirq_pending(x) (__this_cpu_or(local_softirq_pending_ref, (x))) raise_timer_softirq 定时器软中断12345678static in...
spinlock
[toc] kernel/locking/spinlock.c 自旋锁(Spinlock) 内核中最基础的高性能对称多处理器(SMP)锁历史与背景这项技术是为了解决什么特定问题而诞生的?自旋锁(Spinlock)是为了解决**对称多处理器(SMP)**系统中最基础的并发控制问题而诞生的:如何保护一段极短的、在任何执行上下文中都可能被访问的临界区。 在单处理器(UP)系统中,要保护一段临界区,最简单的方法是禁用本地中断。这样可以确保在执行临界区代码时,不会被中断处理程序打断,从而避免了并发。 然而,在多处理器(SMP)系统中,禁用本地CPU的中断并不能阻止另一个CPU同时执行并访问同一块共享数据。因此,需要一种CPU之间的互斥机制。自旋锁就是为此设计的最底层、最高效的锁。它主要解决: SMP互斥:提供一种在多个CPU之间进行互斥的机制。 原子上下文(Atomic Context)保护:中断处理程序、软中断、tasklet等上下文是不能睡眠的。自旋锁通过“忙等待”而不是“睡眠”来等待锁,因此它是唯一可以在这些原子上下文中安全使用的锁类型。 它的发展经历了...
seqlock
[toc] include/linux/seqlock.h 顺序锁(Sequence Lock) 针对读多写少场景的无锁读者优化历史与背景这项技术是为了解决什么特定问题而诞生的?seqlock(顺序锁)是一种高度特化的同步原语,它的诞生是为了解决一个在传统读写锁(rw_lock)中存在的经典性能问题:写者饥饿(Writer Starvation)。 在标准的读写锁模型中,当一个或多个读者持有读锁时,任何试图获取写锁的写者都必须等待。如果读者频繁地、接连不断地到来,那么写者可能会被无限期地延迟,即“饿死”。这在某些读操作极其频繁、写操作较少的场景下会成为严重的性能瓶颈。 seqlock通过颠覆这个模型来解决问题:它赋予写者绝对的优先权。一个写者永远不会被读者阻塞,它可以随时进入临界区并修改数据,即使当时有读者正在读取。为了在这种“不加保护”的读取中保证数据的一致性,它引入了一个序列计数器,让读者自己来检测在读取期间是否有写者介入,并在检测到冲突时进行重试。 它的发展经历了哪些重要的里程碑或版本迭代? 作为一种优化模式被引入:seqlock不是一个通用的锁,...
SRCU
[toc] ![[l kernel/rcu/srcu.c Sleepable Read-Copy Update (SRCU) 允许睡眠的RCU变体历史与背景这项技术是为了解决什么特定问题而诞生的?Sleepable Read-Copy Update (SRCU) 的诞生是为了解决标准RCU(包括Classic RCU和Preemptible RCU)的一个核心限制:其读侧临界区(read-side critical section)内不允许睡眠。 标准的RCU通过监控CPU的静止状态(如上下文切换、进入idle)来确定宽限期(Grace Period),而这些监控手段都假设了读者在持有“锁”(即在rcu_read_lock()和rcu_read_unlock()之间)时不会主动放弃CPU(即睡眠)。 然而,在内核中存在很多场景,开发者需要在访问一个被RCU保护的、读多写少的数据结构的同时,执行一些可能会导致睡眠的操作。例如: 与用户空间交互:调用 copy_from_user() 或 copy_to_user(),这些函数在访问的用户内存被换出到磁盘时,...
tree
[toc] kernel/rcu/tree.c Tree RCU - 应对大规模多核系统的RCU扩展性实现历史与背景这项技術是爲了解决什么特定问题而诞生的?kernel/rcu/tree.c 并不是一种新的RCU“类型”(像SRCU那样),而是标准RCU(包括Preemptible RCU)的一种高性能、高可扩展性的实现方式。它的诞生是为了解决随着多核处理器(SMP)系统中CPU核心数量急剧增加,最初的“扁平化”RCU实现所面临的严重扩展性瓶颈问题。 RCU的核心是等待一个“宽限期”(Grace Period)结束,而宽限期的结束依赖于确认系统中所有CPU都已经经历过至少一次静止状态(Quiescent State)。在早期的、核心数较少的系统中,RCU协调器可以通过检查一个全局的数据结构来轮询或追踪每个CPU的状态。 然而,当CPU核心数从个位数增长到几十、几百甚至上千时,这种“扁平化”的管理方式导致了: 全局锁/数据争用:所有CPU都需要向一个中心点报告自己的状态,或者由一个中心任务去检查所有CPU的状态。这会导致对同一个全局锁或缓存行的...
rcu
[TOC] kernel/rcu Read-Copy Update (RCU) 高性能的内核同步机制历史与背景这项技术是为了解决什么特定问题而诞生的?Read-Copy Update (RCU) 技术的诞生,是为了解决在多核处理器系统中,对**读多写少(Read-mostly)**类型共享数据进行同步时遇到的性能瓶颈问题。 传统的同步机制,如读写锁(Reader-Writer Locks),虽然允许多个读者同时访问数据,但存在以下问题: 读者开销:即使是读取操作,读者也必须获取一个锁(或至少执行原子操作来增加引用计数)。在多核环境下,这会导致缓存行在CPU之间频繁“弹跳”(cache line bouncing),造成严重的性能下降和扩展性问题。 锁争用:当写者需要获取锁时,它可能会被已有的读者阻塞,或者需要等待新的读者完成。反之,写者持有锁时,所有读者都必须等待。这种争用在高并发读取场景下尤为突出。 RCU 的核心目标就是让读者几乎零开销(wait-free)。它允许读者在访问数据时完全不需要获取任何锁、自旋锁或执行原子指令,从而消除了读者端的同步开销和扩展...
idle
[toc] kernel/sched/idle.c 空闲调度(Idle Scheduling) CPU无事可做时的最终选择历史与背景这项技术是为了解决什么特定问题而诞生的?kernel/sched/idle.c 的实现是为了解决一个操作系统中最基础、最本质的问题:当CPU上没有任何有意义的工作(没有可运行的进程或内核线程)时,CPU应该做什么? 一个CPU不能简单地“停止”,它必须始终在执行指令。因此,系统必须提供一个“最后的选择”——一个特殊的任务,在所有其他任务都无法运行时来占用CPU。这个任务就是空闲任务(Idle Task)。 然而,仅仅让CPU执行一个空、、循环(while(1);)是远远不够的,这会带来一个巨大的新问题:功耗。一个在循环中空转的CPU会以最高速度运行,消耗大量电力,产生大量热量,这对于任何设备(尤其是移动设备)都是不可接受的。 因此,idle.c 的核心目标有两个: 提供一个默认的执行流,确保CPU永远有事可做。 实现极致的节能,通过将空闲的CPU置于深度睡眠的低功耗状态来节省能源。 它的发展经历了哪些重要的里程碑或版本迭...
deadline
[toc] kernel/sched/deadline.c 截止时间调度器(Deadline Scheduler, SCHED_DEADLINE) 面向硬实时的可预测调度历史与背景这项技术是为了解决什么特定问题而诞生的?kernel/sched/deadline.c 实现了SCHED_DEADLINE调度策略,它的诞生是为了解决传统实时调度器(SCHED_FIFO/RR)在硬实时(Hard Real-time)和复杂系统中所面临的局限性。 SCHED_FIFO/RR基于静态优先级,虽然模型简单,但在复杂系统中存在两个主要问题: 缺乏可分析性(Analyzability):在一个包含几十个实时任务的系统中,仅仅依靠手动分配静态优先级来保证所有任务都能满足各自的截止时间,是一项极其困难且易错的工作。当任务间存在复杂的依赖关系时,几乎无法从理论上证明系统的可调度性。 任务间无隔离:SCHED_FIFO是“赢家通吃”模型。一个有bug或行为不当的高优先级任务可以无限期地运行,完全饿死所有低优先级任务,导致系统服务完全中断。它不提供任何形式的...
rwsem
[TOC] kernel/locking/rwsem.c 读写信号量(Read-Write Semaphore) 内核中可睡眠的读写锁历史与背景这项技术是为了解决什么特定问题而诞生的?kernel/locking/rwsem.c 实现的读写信号量(Read-Write Semaphore, rwsem)是为了解决rwlock_t(读写自旋锁)无法解决的一类“读多写少”场景的并发控制问题:当临界区的执行时间较长,或者在临界区内需要睡眠时,如何高效地进行读写并发控制。 rwlock_t是一个自旋锁,它要求临界区必须极短且绝对不能睡眠。然而,在内核的许多路径中(特别是与用户空间交互的系统调用),临界区可能很长,并且包含可能导致睡眠的操作(如copy_from_user、kmalloc(GFP_KERNEL)或等待I/O)。 rwsem正是为了这种可睡眠的、读多写少的场景而设计的。它是一个睡眠锁,提供了与rwlock_t相同的逻辑: 允许多个读者并发进入。 只允许一个写者独占进入。 读者和写者互斥。 当一个任务试图获取一个被占用的rwsem时,它不...
fair
[toc] kernel/sched/fair.c 完全公平调度器(Completely Fair Scheduler, CFS) Linux默认的普通进程调度策略历史与背景这项技术是为了解决什么特定问题而诞生的?kernel/sched/fair.c 是Linux内核**完全公平调度器(Completely Fair Scheduler, CFS)**的核心实现。它的诞生是为了彻底取代在它之前的O(1)调度器,并解决其固有的复杂性和公平性问题。 O(1)调度器虽然调度决策速度快,但它依赖于一套非常复杂的、启发式的算法来“猜测”一个进程是否是“交互式”的,并动态地调整其优先级。这导致了以下问题: 公平性不足:其启发式算法并不完美,常常导致某些进程获得不公平的CPU时间份额。 代码复杂难懂:包含大量“魔法数字”和复杂的逻辑,难以维护和调试。 可调优性差:nice值对进程行为的影响不直观,难以预测。 CFS的出现,旨在用一个极其简单、优雅且可证明的公平模型来取代这一切。其核心目标不再是使用复杂的技巧去追踪进程行为,而是去模拟一个**“理想的、完美多任务的...







