wdfk-prog的个人博客

[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()，这些函数在访问的用户内存被换出到磁盘时，...

[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或行为不当的高优先级任务可以无限期地运行，完全饿死所有低优先级任务，导致系统服务完全中断。它不提供任何形式的...

[toc] include/linux/seqlock.h 顺序锁(Sequence Lock) 针对读多写少场景的无锁读者优化历史与背景这项技术是为了解决什么特定问题而诞生的？seqlock（顺序锁）是一种高度特化的同步原语，它的诞生是为了解决一个在传统读写锁（rw_lock）中存在的经典性能问题：写者饥饿（Writer Starvation）。 在标准的读写锁模型中，当一个或多个读者持有读锁时，任何试图获取写锁的写者都必须等待。如果读者频繁地、接连不断地到来，那么写者可能会被无限期地延迟，即“饿死”。这在某些读操作极其频繁、写操作较少的场景下会成为严重的性能瓶颈。 seqlock通过颠覆这个模型来解决问题：它赋予写者绝对的优先权。一个写者永远不会被读者阻塞，它可以随时进入临界区并修改数据，即使当时有读者正在读取。为了在这种“不加保护”的读取中保证数据的一致性，它引入了一个序列计数器，让读者自己来检测在读取期间是否有写者介入，并在检测到冲突时进行重试。 它的发展经历了哪些重要的里程碑或版本迭代？ 作为一种优化模式被引入：seqlock不是一个通用的锁，...

[toc] drivers/irqchip/irqchip.cirqchip_init 初始化函数12345678910//.lds__irqchip_of_table = .; KEEP(*(__irqchip_of_table)) KEEP(*(__irqchip_of_table_end)) . = ALIGN(8);extern struct of_device_id __irqchip_of_table[];void __init irqchip_init(void){ of_irq_init(__irqchip_of_table); acpi_probe_device_table(irqchip);} drivers/irqchip/irq-nvic.cnvic_irq_init 初始化函数1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575...

[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的状态。这会导致对同一个全局锁或缓存行的...

[toc] kernel/sched/syscalls.c 调度相关的系统调用(Scheduler-Related System Calls) 用户空间与调度器交互的接口历史与背景这项技术是为了解决什么特定问题而诞生的？kernel/sched/syscalls.c 这个文件本身并不是一种“技术”，而是用户空间与内核调度器进行交互的官方API层。它的存在是为了解决一个至关重要的问题：如何为一个用户空间的应用程序提供一个稳定、受控且安全的接口，使其能够查询或影响自身以及其他进程的调度行为。 内核调度器（fair.c, rt.c, deadline.c等）是一个极其复杂的内部子系统。如果没有syscalls.c这一层“防火墙”和“翻译官”，就会出现以下问题： 缺乏控制：用户程序将无法请求更高的执行优先级（如实时音频应用）、降低后台任务的影响（如批处理任务），或将任务绑定到特定的CPU核心以优化性能。 安全漏洞：任何程序都可以随意修改系统上所有进程的优先级，一个普通用户进程就能通过提升自己为最高优先级的实时任务来饿死所有其他进程，导致系统完全锁死。 缺乏抽象...

[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的出现，旨在用一个极其简单、优雅且可证明的公平模型来取代这一切。其核心目标不再是使用复杂的技巧去追踪进程行为，而是去模拟一个**“理想的、完美多任务的...

[TOC] kernel/sched 调度器核心(Scheduler Core) 进程调度与上下文切换的决策中心历史与背景这项技术是为了解决什么特定问题而诞生的？kernel/sched/core.c 及其关联文件（如fair.c, rt.c）共同构成了Linux内核的进程调度器（Process Scheduler）。这项技术是为了解决在分时多任务操作系统中一个最根本、最核心的问题：在多个可运行的进程（或线程）之间，如何以及何时分配有限的CPU时间，以达到系统设定的目标。 这些目标通常是相互冲突的，调度器的设计就是在它们之间做出权衡和取舍： 公平性（Fairness）：确保每个普通进程都能获得合理的CPU时间份额，防止任何进程被“饿死”。 吞吐量（Throughput）：最大化系统在单位时间内完成的总工作量。这通常有利于长时间运行的计算密集型任务。 响应性（Responsiveness）：最小化交互式任务（如GUI应用、文本编辑器）的响应延迟，让用户感觉系统“流畅”。这要求任务能被快速唤醒并执行。 实时性（Real-time）：确保需要满足严格截止时间（dead...

[toc] kernel/sched/rt.c 实时调度(Real-Time Scheduling) 保证关键任务的优先执行历史与背景这项技术是为了解决什么特定问题而诞生的？kernel/sched/rt.c 是Linux内核实时调度器的核心实现。它的诞生不是为了“公平”或“高吞吐量”，而是为了解决一个截然不同的、至关重要的问题：可预测的时间行为（Predictable Temporal Behavior）。 在通用计算中（由CFS调度器处理），一个任务晚几毫秒完成通常无伤大雅。但在很多领域，任务的正确性不仅取决于计算结果，更取决于结果产生的时间。如果一个任务错过了它的截止时间（deadline），即使结果正确，也可能造成灾难性后果。这些场景包括： 工业控制：机器人手臂的控制指令必须在几毫秒内发出，否则可能导致生产事故。 电信基础设施：处理5G网络数据包的设备，必须在严格的时间窗内完成，以保证通信质量。 专业音视频处理：音频处理线程必须周期性地、准时地向声卡提供数据，否则就会出现爆音（xrun）。 金融交易：高频交易算法的执行延迟直接关系到经济效益。 ...

[toc] kernel/time/clocksource.c 时钟源管理(Clocksource Management) 内核时间的原始动力历史与背景这项技术是为了解决什么特定问题而诞生的？这项技术是为了在Linux内核中创建一个统一的、可插拔的硬件时钟源抽象层。内核需要一个可靠的方式来读取时间的流逝，而不同的硬件平台提供了种类繁多的硬件定时器/计数器，例如x86上的TSC和HPET，ARM上的System Counter等。这些硬件在精度、稳定性、访问开销等方面都千差万别。 kernel/time/clocksource.c的诞生就是为了解决这个硬件异构性的问题： 抽象硬件差异：它提供了一个标准的struct clocksource接口，将所有不同硬件定时器的具体实现（如如何读取其计数器）封装起来，为上层的timekeeping子系统提供一个统一的、与硬件无关的视图。 选择最佳时钟源：系统中可能同时存在多个可用的时钟源。内核需要一种机制来评估它们各自的优劣（基于频率、分辨率、稳定性等），并从中自动选择一个最佳的来驱动整个系统的时间。 保证...