Linux进程管理核心机制:从调度到RCU的底层原理

每天在 Linux 用ps -ef看进程、top盯 CPU 时,你或许会好奇:多进程抢 CPU,为何浏览器不卡、数据库能响应?高并发下内核读写共享数据,怎没因 “锁” 拖慢速度?答案藏在 Linux 进程管理的两大核心机制里:一是进程调度机制,像 “交通警察” 分配 CPU 资源,决定进程运行优先级与时长,直接影响系统响应;二是RCU 机制,似 “高并发数据管家”,解决多线程读写共享数据的 “快与安全” 难题,多核场景下至关重要。

不管你做后端、运维,还是想深入内核,懂这两大机制都是 “看透 Linux 本质” 的关键 —— 比如明白调度策略,就懂nice命令调优先级的原理;搞懂 RCU,就理解高并发 “无锁访问” 的实现。接下来会从实际问题出发,不堆砌晦涩源码,拆解进程调度的优先级逻辑、调度策略,以及 RCU 的 “读 - 复制 - 更新” 核心思路,帮你搞懂内核如何高效管理资源与数据。

一、RCU 机制是什么?

RCU,全称 Read - Copy - Update,即读 - 拷贝 - 更新,是 Linux 内核中一种用于实现高效并发控制的同步机制,特别适用于读多写少的场景。与传统的锁机制(如互斥锁、读写锁等)不同,RCU 通过独特的设计,尽可能减少读操作的开销,实现读操作的无锁化,从而大大提高系统在高并发读取情况下的性能。

在操作系统中,数据一致性访问是一个非常重要的部分,通常我们可以采用锁机制实现数据的一致性访问。例如,semaphore、spinlock机制,在访问共享数据时,首先访问锁资源,在获取锁资源的前提下才能实现数据的访问。这种原理很简单,根本的思想就是在访问临界资源时,首先访问一个全局的变量(锁),通过全局变量的状态来控制线程对临界资源的访问。但是,这种思想是需要硬件支持的,硬件需要配合实现全局变量(锁)的读-修改-写,现代CPU都会提供这样的原子化指令。采用锁机制实现数据访问的一致性存在如下两个问题:

效率问题。锁机制的实现需要对内存的原子化访问,这种访问操作会破坏流水线操作,降低了流水线效率。这是影响性能的一个因素。另外,在采用读写锁机制的情况下,写锁是排他锁,无法实现写锁与读锁的并发操作,在某些应用下会降低性能。扩展性问题。当系统中CPU数量增多的时候,采用锁机制实现数据的同步访问效率偏低。并且随着CPU数量的增多,效率降低,由此可见锁机制实现的数据一致性访问扩展性差。

图片

读者无锁访问:在 RCU 机制下,读者线程在访问被保护的共享数据时,不需要获取任何锁。这意味着多个读者线程可以同时并发地访问共享数据,而不会因为锁竞争而产生等待和性能损耗 。例如,在一个多线程的文件系统中,当多个线程需要读取文件目录结构时,如果采用 RCU 机制,这些读操作可以并行进行,极大提高了读取效率。写者复制更新:当写者线程需要修改共享数据时,不会直接在原数据上进行操作。相反,写者会首先创建一个原数据的副本,然后在这个副本上进行修改。修改完成后,通过一个原子操作,将指向原数据的指针更新为指向新的修改后的副本。这样做的好处是,在写者进行修改的过程中,读者线程仍然可以继续访问原数据,不会受到写操作的影响。比如,在更新网络设备的配置信息时,写者先复制当前配置数据,修改副本后再更新指针,读配置信息的线程不会被打断。宽限期(Grace Period):在写者完成数据更新并切换指针后,并不会立即释放旧数据的内存空间。这是因为可能还有一些读者线程在写操作开始前就已经进入临界区,正在访问旧数据。只有当所有在写操作开始前进入临界区的读者都退出临界区后,旧数据才会被安全地释放。从写者完成更新到旧数据被释放的这段时间,就称为宽限期。宽限期的实现依赖于内核中对 CPU 上下文切换等事件的监测,当所有 CPU 都经历了一次上下文切换(表示之前的读操作都已完成),宽限期结束,旧数据可以被回收。发布 - 订阅模式(Publish-Subscribe Pattern):为了确保读者和写者之间的数据一致性,RCU 机制引入了发布 - 订阅模式。写者在完成数据修改并准备切换指针时,通过特定的操作(如rcu_assign_pointer)“发布” 新的数据。读者在访问共享数据时,使用rcu_dereference操作 “订阅” 数据。这些操作结合内存屏障(Memory Barrier)技术,保证了写者发布新数据的操作对读者可见,同时防止指令重排序导致的数据不一致问题。例如,在路由表更新场景中,写者更新路由表后发布新表,读者通过订阅获取最新且一致的路由信息用于数据转发。

RCU的关键思想有两个:①复制后更新;②延迟回收内存。典型的RCU更新时序如下:

复制:将需要更新的数据复制到新内存地址;更新:更新复制数据,这时候操作的新的内存地址;替换:使用新内存地址指针替换旧数据内存地址指针,此后旧数据将无法被后续读者访问;等待,所有访问旧数据的读者进入静默期,即访问旧数据完成;回收:当没有任何持有旧数据结构引用的读者后,安全地回收旧数据内存。

二、RCU 机制如何工作?

RCU 机制的工作原理主要围绕读操作和写操作展开,同时涉及宽限期的管理,以确保数据一致性和高效的并发访问。

2.1读操作流程

进入临界区:读者线程在访问被 RCU 保护的共享数据前,调用rcu_read_lock函数。这个函数的主要作用是标记读操作的开始,同时通过preempt_disable关闭内核抢占(防止在读取过程中被其他高优先级任务抢占,导致数据访问不一致),但允许中断发生。例如,在一个多线程的数据库查询场景中,当一个线程调用rcu_read_lock后,它就开始了对数据库表结构(共享数据)的读取操作,此时不会因为内核调度其他任务而被打断读取流程。数据访问:进入临界区后,读者线程使用rcu_dereference操作来安全地获取指向共享数据的指针并访问数据。rcu_dereference结合内存屏障技术,确保读者线程能够看到最新的、一致的数据。比如在读取网络配置参数时,rcu_dereference能保证读取到的是完整且最新的配置信息,而不会因为写操作正在进行而读到部分更新或不一致的数据。离开临界区:完成数据访问后,读者线程调用rcu_read_unlock函数,标记读操作的结束,并通过preempt_enable重新开启内核抢占。这样,系统又可以正常调度其他任务,不会因为本次读操作而影响系统的整体调度。
复制
#include <linux/rculist.h> #include <linux/sched.h> #include <linux/module.h> // 定义一个被RCU保护的共享数据结构(示例:简单链表节点) struct rcu_demo_node { int data; struct list_head list; }; // 全局共享链表(被RCU保护) static LIST_HEAD(rcu_demo_list); static DEFINE_SPINLOCK(rcu_demo_lock); // 写操作时使用的锁 // RCU读操作示例函数 static void rcu_reader_example(void) { struct rcu_demo_node *node; // 1. 进入RCU读临界区:禁用抢占,标记读操作开始 rcu_read_lock(); // 2. 安全访问共享数据:通过rcu_dereference获取指针并遍历 list_for_each_entry_rcu(node, &rcu_demo_list, list) { // 访问数据(此时即使有写操作,也能看到一致的旧版本或新版本数据) pr_info("RCU Reader: Read data = %d\n", node->data); } // 3. 退出RCU读临界区:恢复抢占,标记读操作结束 rcu_read_unlock(); } // 模块初始化函数(示例:启动一个读操作) static int __init rcu_demo_init(void) { pr_info("RCU demo module loaded\n"); rcu_reader_example(); // 执行RCU读操作 return 0; } // 模块退出函数 static void __exit rcu_demo_exit(void) { pr_info("RCU demo module unloaded\n"); } module_init(rcu_demo_init); module_exit(rcu_demo_exit); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("RCU Read Operation Example");1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50.
进入临界区:rcu_read_lock() 函数会禁用当前线程的内核抢占(通过 preempt_disable),同时将当前线程标记为活跃的 RCU 读者。这一步确保读操作不会被内核调度打断,避免延长写操作的等待时间。数据访问:使用 list_for_each_entry_rcu 宏遍历链表(内部封装了 rcu_dereference),确保通过 RCU 安全机制获取指针。该宏会插入内存屏障,防止 CPU 指令重排序,保证读取到的数据是一致的快照。退出临界区:rcu_read_unlock() 函数恢复内核抢占(preempt_enable),并解除当前线程的 RCU 读者标记。此时若有写操作等待回收旧数据,系统会在所有读者退出后进行清理。

注意:此代码为内核态示例,RCU 是 Linux 内核的同步机制,用户态程序通常不直接使用。实际使用中,还需要配合写操作的 RCU 机制(如 rcu_assign_pointer、call_rcu 等)才能完整工作。

2.2写操作流程

复制数据:当写者线程需要修改共享数据时,首先分配一块新的内存空间,用于存放数据的副本。例如,在更新一个链表节点的数据时,写者会创建一个新的节点,其结构与原节点相同。然后将原数据的内容完整地复制到新的副本中。以更新文件系统的元数据为例,写者会复制当前的元数据结构到新的内存区域,确保新副本包含原数据的所有信息。修改副本:在新的副本上进行数据修改操作。由于这是对副本进行修改,不会影响正在被读者线程访问的原数据,保证了读操作的连续性和一致性。比如在修改路由表项时,写者在副本上更新目标地址、下一跳等信息,整个修改过程对读路由表的线程透明。指针替换:完成修改后,写者使用一个原子操作(如rcu_assign_pointer)将指向原数据的指针更新为指向新的修改后的副本。这个原子操作保证了指针切换的原子性,避免了读者线程看到不一致的指针状态。例如,在更新系统的设备列表时,通过原子操作切换指针,使得新的设备列表信息能够立即被后续的读操作获取到,同时保证了当前正在进行的读操作不会受到影响。注册回调函数:写者注册一个回调函数,用于在宽限期结束后释放旧数据的内存空间。这个回调函数会被加入到 RCU 的回调函数队列中,等待宽限期结束后执行。
复制
#include <linux/rculist.h> #include <linux/sched.h> #include <linux/module.h> #include <linux/slab.h> // 定义带RCU头的共享数据结构 struct rcu_demo_node { int data; struct list_head list; struct rcu_head rcu; // 用于RCU回调回收 }; // 全局共享链表及写锁 static LIST_HEAD(rcu_demo_list); static DEFINE_SPINLOCK(rcu_demo_lock); // 旧数据回收回调函数 static void rcu_node_free(struct rcu_head *rcu) { struct rcu_demo_node *node = container_of(rcu, struct rcu_demo_node, rcu); kfree(node); // 宽限期结束后释放旧节点 pr_info("RCU Writer: Old node freed\n"); } // RCU写操作示例函数(修改指定节点数据) static void rcu_writer_example(int old_val, int new_val) { struct rcu_demo_node *old_node, *new_node; unsigned long flags; // 1. 查找需要修改的旧节点(简化示例,实际需遍历查找) spin_lock_irqsave(&rcu_demo_lock, flags); list_for_each_entry(old_node, &rcu_demo_list, list) { if (old_node->data == old_val) { // 2. 复制数据:分配新节点并复制旧数据 new_node = kmalloc(sizeof(*new_node), GFP_KERNEL); if (!new_node) { spin_unlock_irqrestore(&rcu_demo_lock, flags); return; } *new_node = *old_node; // 复制旧节点数据 // 3. 修改副本:在新节点上修改数据 new_node->data = new_val; pr_info("RCU Writer: Modified data from %d to %d\n", old_val, new_val); // 4. 指针替换:原子替换链表节点 list_replace_rcu(&old_node->list, &new_node->list); // 5. 注册回调:宽限期后释放旧节点 call_rcu(&old_node->rcu, rcu_node_free); break; } } spin_unlock_irqrestore(&rcu_demo_lock, flags); } // 初始化函数:添加测试节点并执行写操作 static int __init rcu_demo_init(void) { struct rcu_demo_node *node; unsigned long flags; // 初始化测试节点 node = kmalloc(sizeof(*node), GFP_KERNEL); node->data = 100; spin_lock_irqsave(&rcu_demo_lock, flags); list_add_rcu(&node->list, &rcu_demo_list); spin_unlock_irqrestore(&rcu_demo_lock, flags);1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50.51.52.53.54.55.56.57.58.59.60.61.62.63.64.65.66.67.68.69.
复制数据:通过kmalloc分配新节点,使用*new_node = *old_node完整复制旧节点数据,确保新副本包含所有原始信息。修改副本:直接在新节点new_node上修改目标字段(new_node->data = new_val),此操作完全独立于旧节点,不影响读者对旧数据的访问。指针替换:使用list_replace_rcu宏(内部封装rcu_assign_pointer)原子性替换链表节点,保证读者要么看到旧指针,要么看到新指针,不会出现中间状态。注册回调:通过call_rcu注册rcu_node_free回调函数,RCU 机制会在所有活跃读者退出临界区(宽限期结束)后自动执行该函数,安全释放旧节点内存。

此示例完整展示了 RCU"读无锁、写复制" 的核心思想,写操作不会阻塞读操作,读操作也不会阻塞写操作,大幅提升了高并发场景下的性能。

2.3宽限期的作用与实现

在 RCU(Read-Copy-Update)机制中,宽限期(Grace Period)是保障数据安全回收的核心机制,其设计直接决定了 RCU 在并发场景下的正确性。

三、RCU 机制的优势

3.1性能提升

在高并发读取场景下,RCU 机制通过允许读者无锁访问共享数据,显著减少了锁竞争和同步开销,从而极大地提升了系统性能。在传统的锁机制中,当多个读者线程试图同时访问共享数据时,会因为锁的存在而产生竞争。例如,使用互斥锁时,每次只能有一个线程获取锁并访问数据,其他线程必须等待锁的释放,这会导致大量的上下文切换和等待时间,严重降低系统的并发处理能力。

而在 RCU 机制下,读者线程无需获取锁即可直接访问共享数据。以一个多线程的数据库查询系统为例,假设有大量的查询线程(读者)需要读取数据库中的用户信息表(共享数据)。在高并发情况下,如果使用传统锁机制,线程之间会频繁竞争锁资源,导致查询操作的延迟增加。但采用 RCU 机制后,这些查询线程可以同时无锁地读取用户信息表,大大提高了查询的并发处理能力,减少了响应时间 。

3.2扩展性好

RCU 机制在多核系统中展现出良好的扩展性,不会随着 CPU 数量的增加而导致性能下降。随着硬件技术的发展,多核处理器被广泛应用,系统中 CPU 核心数量不断增多。在这种情况下,传统的同步机制面临着严峻的挑战。例如,自旋锁在多核环境下,如果多个 CPU 核心同时竞争同一个锁,会导致大量的 CPU 时间浪费在自旋等待上,随着 CPU 数量的增加,这种竞争会更加激烈,从而严重影响系统性能。而 RCU 机制的设计理念使其天然适合多核环境。在多核系统中,每个 CPU 核心上的线程都可以作为读者无锁地访问共享数据,不会因为 CPU 数量的增加而产生额外的锁竞争开销。

例如,在一个具有多个 CPU 核心的服务器系统中,网络路由表(共享数据)需要被频繁读取和偶尔更新。使用 RCU 机制,各个 CPU 核心上的网络处理线程可以高效地读取路由表,而写者线程在更新路由表时,也不会影响其他 CPU 核心上的读操作,系统的整体性能能够随着 CPU 核心数量的增加而线性提升 。

3.3无死锁风险

死锁是多线程编程中常见的问题,当多个线程相互等待对方释放锁资源时,就会陷入死锁状态,导致程序无法继续执行。传统的锁机制,如互斥锁、读写锁等,如果使用不当,很容易出现死锁问题。例如,线程 A 持有锁 1 并试图获取锁 2,而线程 B 持有锁 2 并试图获取锁 1,此时就会发生死锁。而 RCU 机制能有效避免死锁问题。

在 RCU 中,读者线程在访问共享数据时不需要获取锁,这就从根本上消除了因为读者和写者之间或读者之间的锁依赖而导致的死锁可能性。写者线程虽然在更新数据时需要进行一些同步操作,但由于其采用复制更新和宽限期的策略,也不会与读者线程形成死锁关系。例如,在一个多线程的文件系统实现中,使用 RCU 机制来保护文件元数据的访问。读者线程在读取文件元数据时无需锁,写者线程在更新元数据时,先复制数据进行修改,然后等待宽限期结束后才替换旧数据,整个过程中不存在锁的循环等待情况,确保了系统的稳定性和可靠性 。

四、RCU 机制的局限性

4.1写操作开销大

RCU 机制虽然在提升读操作性能方面表现出色,但写操作却存在较大开销。写者在更新数据时,需要进行数据复制操作,这不仅消耗额外的内存资源,还增加了时间开销。以更新一个包含大量元素的数组为例,写者需要分配新的内存空间,并将原数组的所有元素逐一复制到新的副本中,这个过程会占用较多的内存带宽和 CPU 时间。

此外,写者还需要等待宽限期结束后才能释放旧数据的内存空间,这意味着在宽限期内,系统需要维护新旧两份数据,进一步增加了内存的使用压力。如果写操作频繁发生,这些开销可能会对系统的整体性能产生显著影响,导致系统响应变慢、内存利用率降低等问题 。

4.2适用场景有限

RCU 机制主要适用于读多写少的场景,在这种场景下,其无锁读的特性能够充分发挥优势,提高系统的并发性能。然而,在写操作频繁的场景中,RCU 机制的性能表现可能并不理想。由于写者在更新数据时需要复制数据和等待宽限期,这会导致写操作的延迟增加。例如,在一个实时数据库系统中,如果写操作频繁,RCU 机制可能无法满足系统对写操作的实时性要求。

此外,对于那些需要频繁进行数据一致性更新的场景,RCU 机制可能也不太适用。因为 RCU 机制在更新数据时,存在一定的时间窗口,期间读者可能会读取到旧数据,这在一些对数据一致性要求极高的场景(如金融交易系统)中是不可接受的 。

4.3实现复杂

RCU 机制的实现依赖于底层的内存屏障和原子操作等技术,这使得其实现和理解都相对复杂。内存屏障用于确保内存操作的顺序性和可见性,防止 CPU 或编译器的优化导致数据不一致问题。原子操作则用于保证数据更新的原子性,避免并发访问时的数据冲突。例如,在 x86 架构下,rcu_assign_pointer函数中会使用特定的内存屏障指令(如mfence)来确保指针更新的可见性和顺序性。这些底层技术对于开发者来说,需要深入了解硬件和操作系统的原理才能正确运用。此外,RCU机制的调试也比较困难,因为其涉及到复杂的并发控制和宽限期管理。当出现数据不一致或性能问题时,很难快速定位和解决问题,需要开发者具备丰富的经验和深入的知识 。

五、RCU 机制的应用场景

5.1内核数据结构管理

在 Linux 内核中,链表和哈希表是常用的数据结构,用于管理各种系统资源和信息。RCU 机制在这些数据结构的管理中发挥着重要作用,极大地提高了内核在多线程环境下的并发性能。

以链表为例,在传统的链表操作中,如果多个线程同时对链表进行读写操作,需要使用锁机制来保证数据的一致性和完整性。例如,当一个线程要遍历链表(读操作)时,另一个线程可能正在删除链表中的节点(写操作),如果没有锁的保护,读操作可能会访问到已经被删除的节点,导致程序崩溃或数据错误。

而使用 RCU 机制,读者线程在遍历链表时不需要获取锁,可以无锁并发地访问链表。当写者线程要删除链表中的节点时,先将节点从链表中移除,但并不立即释放该节点的内存。而是等待宽限期结束,确保所有可能访问该节点的读者线程都已完成访问后,再安全地释放节点内存。这样,既保证了读操作的高效性,又确保了写操作不会影响正在进行的读操作 。

对于哈希表,RCU 机制同样能提升其并发性能。哈希表常用于快速查找数据,在 Linux 内核中,如网络协议栈中的路由表就常以哈希表的形式实现。当多个线程需要查找哈希表中的数据(读操作)时,RCU 机制允许它们无锁地进行并发查找,提高了查找效率。而当写者线程要更新哈希表中的数据(如添加或删除一个路由表项)时,先创建一个新的哈希表副本,在副本上进行修改,然后通过原子操作将指向原哈希表的指针更新为指向新的副本。在宽限期内,旧的哈希表仍然保留,以确保正在进行的读操作可以继续正常进行。这种方式避免了传统锁机制下读写操作相互等待的问题,提高了哈希表在高并发环境下的性能和稳定性 。

5.2文件系统

在文件系统中,文件元数据包含了文件的各种属性信息,如文件大小、创建时间、所有者等,对文件元数据的高效读写对于文件系统的性能至关重要。RCU 机制通过其独特的设计,有效地提升了文件系统对文件元数据的处理能力。

当多个线程需要读取文件元数据时,RCU 机制允许这些读操作无锁并发进行。例如,在一个多用户的服务器系统中,多个用户可能同时查看同一个目录下的文件列表,每个用户的操作都涉及读取文件元数据。使用 RCU 机制,这些读操作可以并行执行,大大提高了文件系统的响应速度,减少了用户等待时间。

而当写者线程需要更新文件元数据时,如修改文件的权限或所有者信息,写者首先复制当前的文件元数据结构,在副本上进行修改。完成修改后,通过原子操作将指向原文件元数据的指针更新为指向新的修改后的副本。在宽限期内,旧的文件元数据仍然可供读者线程访问,确保了读操作的连续性。只有当宽限期结束,所有可能访问旧文件元数据的读者线程都完成访问后,旧的文件元数据才会被安全地释放。这种方式避免了传统锁机制下读写操作相互阻塞的问题,提高了文件系统在处理大量并发读写请求时的性能和稳定性 。

5.3网络协议栈

在网络协议栈中,路由表用于存储网络路由信息,指导数据包的转发。路由表的查询操作非常频繁,而更新操作相对较少,这使得 RCU 机制成为优化路由表操作的理想选择。

当网络设备接收到一个数据包时,需要查询路由表来确定数据包的转发路径。在高并发的网络环境中,可能有大量的数据包同时到达,需要频繁查询路由表。使用 RCU 机制,多个查询线程(读者)可以无锁并发地访问路由表,大大提高了查询效率,确保数据包能够快速转发,减少网络延迟。

当网络拓扑发生变化或新的路由信息加入时,需要更新路由表(写操作)。写者线程在更新路由表时,首先创建一个新的路由表副本,在副本上进行修改,如添加、删除或修改路由表项。修改完成后,通过原子操作将指向原路由表的指针更新为指向新的副本。在宽限期内,旧的路由表仍然保留,以确保正在进行的查询操作可以继续正常进行。这样,既保证了路由表查询操作的高效性,又确保了路由表更新操作不会影响网络数据包的正常转发,提高了网络通信的效率和稳定性 。

六、如何使用 RCU 机制

6.1相关 API 介绍

如果指针ptr指向被RCU保护的数据结构,直接反引用指针是被禁止的,首先必须调用rcu_dereference(ptr),然后反引用返回的结果,需要使用rcu_read_lock和rcu_read_unlock调用来进行保护。

复制
rcu_read_lock() rcu_read_unlock() synchronize_rcu()/call_rcu() rcu_assign_pointer() rcu_dereference()1.2.3.4.5.

①rcu_read_lock():用于标记读操作的开始,关闭内核抢占,确保在读取共享数据期间不会因为内核调度而被打断,从而保证数据访问的一致性。例如在文件系统中读取文件目录结构时,调用rcu_read_lock()可以防止在读取过程中被其他高优先级任务抢占,导致目录结构读取不完整。它的实现原理主要是通过preempt_disable来禁止内核抢占,在一些不支持抢占的内核中,可能仅仅是执行一条内存屏障指令 。

复制
void rcu_read_lock(void);1.

读者读取受RCU保护的数据结构时使用,通知回收者读者进入了RCU的读端临界区。在RCU读端临界区访问的任何受RCU保护的数据结构都会保证在临界区期间保持未回收状态。另外,引用计数可以与RCU一起使用,以维护对数据结构的长期引用。在RCU读侧临界区阻塞是非法的。rcu_read_lock的实现非常简单,是关闭抢占:

复制
static inline void __rcu_read_lock(void) { preempt_disable(); }1.2.3.4.

②rcu_read_unlock():与rcu_read_lock()成对使用,标记读操作的结束,重新开启内核抢占。例如在完成对文件目录结构的读取后,调用rcu_read_unlock(),系统就可以正常调度其他任务,不会因为本次读操作而影响系统的整体调度。它通过preempt_enable来实现重新开启内核抢占的功能。

复制
void rcu_read_unlock(void);1.

读者结束读取后使用,用于通知回收者其退出了读端临界区。RCU的读端临界区可能被嵌套或重叠。rcu_read_unlock的实现是开发抢占。

复制
static inline void __rcu_read_unlock(void) { preempt_enable(); }1.2.3.4.

③synchronize_rcu():写者调用该函数,等待宽限期结束,即等待所有在写操作开始前进入临界区的读者都退出临界区。在更新网络设备的配置信息时,写者完成配置数据的修改并切换指针后,调用synchronize_rcu(),确保所有可能访问旧配置信息的读者都已经完成访问,然后才进行后续的操作,如释放旧数据的内存空间,保证了数据的一致性和安全性 。

复制
void synchronize_rcu(void);1.

synchronize_rcu 函数的关键思想是等待。确保读者完成对旧结构体的操作后释放旧结构体。synchronize_rcu 的调用点标志着“更新者代码的结束”和“回收者代码的开始”。它通过阻塞来做到这一点,直到所有cpu上所有预先存在的RCU读端临界区都完成。

需要注意的是,synchronize_rcu()只需要等待调用它之前的读端临界区完成,不需要等待调用它之后开始的读取者完成。另外,synchronize_rcu()不一定在最后一个预先存在的RCU读端临界区完成之后立即返回。具体实现中可能会有延时调度。同时,为了提高效率,许多RCU实现请求批量处理,这可能会进一步延迟 synchronize_rcu() 的返回。

④call_rcu():写者使用这个函数注册一个回调函数,该回调函数会在宽限期结束后被调用,通常用于释放旧数据的内存空间。例如在删除链表节点时,写者调用call_rcu()注册一个释放节点内存的回调函数,当宽限期结束,所有可能访问该节点的读者都已完成访问后,系统会自动调用这个回调函数,安全地释放节点内存 。

在上面的例子中,rcu_st_update阻塞直到一个宽限期结束。这很简单,但在某些情况下,人们不能等这么久——可能还有其他高优先级的工作要做。 在这种情况下,使用call_rcu()而不是synchronize_rcu()。call_rcu() API如下:

复制
void call_rcu(struct rcu_head * head, void (*func)(struct rcu_head *head));1.

此函数在宽限期过后调用func(heda)。此调用可能发生在softirq或进程上下文中,因此不允许阻止该函数。rcu_st结构需要添加一个rcu-head结构,可能如下所示:

复制
struct foo { int a; char b; long c; struct rcu_head rcu; };1.2.3.4.5.6.

foo_update_a()函数示例如下:

复制
/* * Create a new struct foo that is the same as the one currently * * pointed to by gbl_foo, except that field "a" is replaced * * with "new_a". Points gbl_foo to the new structure, and * * frees up the old structure after a grace period. * * Uses rcu_assign_pointer() to ensure that concurrent readers * * see the initialized version of the new structure. * * Uses call_rcu() to ensure that any readers that might have * * references to the old structure complete before freeing the * old structure. * */ void foo_update_a(int new_a) { struct foo *new_fp = NULL; struct foo *old_fp = NULL; new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL); spin_lock(&foo_mutex); old_fp = rcu_dereference_protected(gbl_foo, lockdep_is_held(&foo_mutex)); *new_fp = *old_fp; new_fp->a = new_a; rcu_assign_pointer(gbl_foo, new_fp); spin_unlock(&foo_mutex); /* 挂接释放函数 */ call_rcu(&old_fp->rcu, foo_reclaim); } // The foo_reclaim() function might appear as follows: void foo_reclaim(struct rcu_head *rp) { struct foo *fp = container_of(rp, struct foo, rcu); foo_cleanup(fp->a); kfree(fp); }1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.

container_of() 原语是一个宏,给定指向结构的指针,结构的类型以及结构内的指向字段,该宏将返回指向结构开头的指针。

使用 call_rcu() 可使 foo_update_a() 的调用方立即重新获得控制权,而不必担心新近更新的元素的旧版本。 它还清楚地显示了更新程序 foo_update_a()和回收程序 foo_reclaim() 之间的RCU区别。

在从受RCU保护的数据结构中删除数据元素之后,请使用call_rcu()-以注册一个回调函数,该函数将在所有可能引用该数据项的RCU读取侧完成后调用。如果call_rcu()的回调除了在结构上调用kfree()之外没有做其他事情,则可以使用kfree_rcu()代替call_rcu()来避免编写自己的回调:kfree_rcu(old_fp,rcu)

⑤rcu_assign_pointer():写者在完成数据修改并准备切换指针时,使用这个函数将指向原数据的指针更新为指向新的修改后的副本。这个函数结合内存屏障技术,保证了指针更新操作的原子性和可见性,确保读者能够看到最新的、一致的数据。比如在更新系统的设备列表时,写者通过 rcu_assign_pointer() 将指向旧设备列表的指针更新为指向新的设备列表,使得新的设备列表信息能够立即被后续的读操作获取到,同时保证了当前正在进行的读操作不会受到影响 。

复制
voidrcu_assign_pointer(p,typeof(p)v);1.

rcu_assign_pointer()通过宏实现。将新指针赋给RCU结构体,赋值前的读者看到的还是旧的指针。更新者使用这个函数为受rcu保护的指针分配一个新值,以便安全地将更新的值更改传递给读者。 此宏不计算rvalue,但它执行某CPU体系结构所需的内存屏障指令。保证内存屏障前的指令一定会先于内存屏障后的指令被执行。

它用于记录:哪些指针受 RCU 保护以及给定结构可供其他CPU访问的点,rcu_assign_pointer()最常通过_rcu列表操作原语(例如list_add_rcu())间接使用。

⑥rcu_dereference():读者使用这个函数来安全地获取指向共享数据的指针并访问数据。它结合内存屏障技术,确保读者能够看到最新的、一致的数据,避免了因为读写并发导致的数据不一致问题。例如在读取网络配置参数时,读者通过rcu_dereference()获取指向配置数据的指针,能保证读取到的是完整且最新的配置信息,而不会因为写操作正在进行而读到部分更新或不一致的数据 。

复制
typeof(p) rcu_dereference(p);1.

与rcu_assign_pointer()类似,rcu_dereference()也必须通过宏实现。读者通过rcu_dereference()获取受保护的RCU指针,该指针返回一个可以安全解除引用的值。 请注意,rcu_dereference()实际上并未取消对指针的引用,相反,它保护指针供以后取消引用。 它还针对给定的CPU体系结构执行任何所需的内存屏障指令。

常见的编码实践是使用rcu_dereference() 将一个受rcu保护的指针复制到一个局部变量,然后解引用这个局部变量,例如:

复制
p = rcu_dereference(head.next); return p->data;1.2.

然而,上述情况可以整合成如下一句:

复制
return rcu_dereference(head.next)->data;1.

6.2代码示例

下面是一个使用 RCU 机制保护链表的代码示例,包括添加节点、删除节点和遍历节点的操作:

复制
#include <linux/module.h> #include <linux/init.h> #include <linux/kernel.h> #include <linux/slab.h> #include <linux/rcupdate.h> #include <linux/list.h> // 定义链表节点结构 struct my_node { int data; struct list_head list; struct rcu_head rcu; }; // 定义链表头 static LIST_HEAD(my_list); // 添加节点函数 void add_node(int new_data) { struct my_node *new_node = kmalloc(sizeof(struct my_node), GFP_KERNEL); if (!new_node) { return; } new_node->data = new_data; // 使用RCU机制添加节点 list_add_rcu(&new_node->list, &my_list); } // 删除节点函数 void remove_node(struct my_node *node) { // 使用RCU机制删除节点 list_del_rcu(&node->list); // 注册回调函数,在宽限期结束后释放节点内存 call_rcu(&node->rcu, (void (*)(struct rcu_head *))kfree); } // 遍历节点函数 void traverse_list(void) { struct my_node *entry; // 进入RCU读临界区 rcu_read_lock(); list_for_each_entry_rcu(entry, &my_list, list) { printk(KERN_INFO "Node data: %d\n", entry->data); } // 离开RCU读临界区 rcu_read_unlock(); } static int __init my_module_init(void) { add_node(10); add_node(20); traverse_list(); struct my_node *node_to_remove = list_entry(my_list.next, struct my_node, list); remove_node(node_to_remove); traverse_list(); return 0; } static void __exit my_module_exit(void) { struct my_node *entry, *tmp; // 确保所有RCU操作完成 synchronize_rcu(); list_for_each_entry_safe_rcu(entry, tmp, &my_list, list) { list_del_rcu(&entry->list); kfree(entry); } } module_init(my_module_init); module_exit(my_module_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Your Name"); MODULE_DESCRIPTION("RCU Linked List Example");1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50.51.52.53.54.55.56.57.58.59.60.61.62.63.64.65.66.67.68.69.70.71.72.73.74.75.76.
add_node函数用于向链表中添加新节点,通过kmalloc分配内存,然后使用list_add_rcu将新节点添加到链表中。remove_node函数用于从链表中删除指定节点,首先使用list_del_rcu删除节点,然后通过call_rcu注册一个回调函数kfree,在宽限期结束后释放节点的内存。traverse_list函数用于遍历链表,在遍历之前调用rcu_read_lock进入 RCU 读临界区,遍历结束后调用rcu_read_unlock离开临界区,确保在遍历过程中链表不会被修改,保证数据的一致性 。在模块初始化函数my_module_init中,先添加两个节点,然后遍历链表,接着删除一个节点,再次遍历链表以验证删除操作的正确性。在模块退出函数my_module_exit中,先调用synchronize_rcu等待所有 RCU 操作完成,确保所有可能访问链表节点的读者都已完成访问,然后安全地释放链表中剩余节点的内存 。

THE END