1. 项目概述为什么内核同步是Linux的基石在Linux的世界里内核同步机制这个话题听起来有点硬核甚至有点枯燥。但如果你真的动手写过内核模块或者深入调试过并发问题你就会明白这玩意儿是决定系统是稳定如山还是分崩离析的关键。它不像用户态编程一个pthread_mutex_lock就能解决大部分烦恼。在内核这个“无法无天”的环境里中断随时可能打断你多个CPU核心可能同时操作同一块数据甚至一个写操作还没完成另一个读操作就冲了进来。结果呢数据损坏、系统死锁、或者更诡异的“灵异”崩溃查起来能让人掉光头发。我干了十多年系统底层开发踩过的坑不计其数。很多新手甚至一些有经验的开发者在用户态玩得风生水起一进内核就懵了。他们习惯用用户态的思维去理解内核觉得锁嘛不就是让代码一段一段执行吗但内核的并发场景复杂太多了进程上下文、中断上下文、软中断、内核线程、多处理器SMP……这些执行流交织在一起对共享数据的访问就像在一个没有交通灯的十字路口飙车不出事才怪。所以理解Linux内核同步机制绝不仅仅是为了应付面试或者炫技。它是你深入理解操作系统如何工作、如何写出健壮可靠的内核代码、乃至如何设计高并发系统的基础。无论是做驱动开发、性能优化、还是搞容器、eBPF这些时髦技术底层都绕不开同步这道坎。接下来我就结合自己的实战经验掰开揉碎了讲讲这里面的门道。2. 内核同步的核心挑战与设计哲学2.1 并发执行的“混乱”源头在用户态我们主要关心多线程。但在内核态并发的来源要多得多这也是内核同步复杂性的根源。主要可以归结为以下几类对称多处理SMP这是最直观的。多个CPU核心同时执行它们共享物理内存。核心A正在修改一个链表核心B也试图遍历这个链表如果没有同步B读到的可能就是一半新、一半旧的数据或者直接触发一个内核异常。内核抢占现代Linux内核是可抢占的CONFIG_PREEMPT。这意味着即使是在单个CPU上一个进程在内核态执行时也可能被另一个更高优先级的进程抢占。被抢占的点可能正好在修改共享资源的中间。中断硬件中断可以随时发生打断当前正在执行的代码无论是用户态还是内核态。中断处理程序ISR很可能需要访问和进程上下文相同的全局数据。比如网卡中断处理程序收到一个数据包要把它放入一个由协议栈管理的接收队列中。软中断和Tasklet为了缩短中断处理时间Linux将中断处理分为“上半部”和“下半部”。下半部通常以软中断或Tasklet的形式执行它们同样可能在任何一个CPU上异步执行并与进程上下文并发访问数据。内核线程一些内核后台任务如kswapd内存回收、kworker等它们也会访问各种内核数据结构。所有这些执行流交织在一起形成了一个立体的、错综复杂的并发网络。内核同步机制的设计目标就是在保证正确性的前提下尽可能地提升性能减少锁带来的开销。2.2 临界区与竞态条件问题的本质无论并发源头多么复杂问题的核心都围绕着“临界区”和“竞态条件”。临界区访问和操作共享资源变量、链表、设备寄存器等的那段代码。竞态条件两个或以上的执行流同时进入临界区导致执行结果依赖于它们相对的执行时序从而产生不可预测的行为。内核同步机制本质上就是设计各种“工具”来保证在任意时刻最多只有一个执行流处于某个特定的临界区内。听起来简单但难点在于性能锁的粒度太粗比如一个锁锁住整个网络栈性能会急剧下降粒度太细管理复杂容易死锁。死锁多个执行流互相等待对方持有的锁导致所有相关任务“卡死”。可扩展性随着CPU核心数增加同步机制不能成为瓶颈。中断环境在中断上下文中有些同步原语如可能导致睡眠的信号量是不能使用的。理解了这些挑战我们再看Linux提供的“工具箱”就会明白每种工具为什么存在以及应该在什么场景下使用。3. 同步机制工具箱详解与选型指南Linux内核提供了丰富的同步机制就像一套精密的瑞士军刀每把刀都有其特定的用途。用错了地方要么事倍功半要么直接“翻车”。3.1 原子操作最基础的“不可分割”指令原子操作是所有同步机制的基石。它保证对一个整型变量的“读-改-写”操作在CPU层面是原子的中间不会被其他执行流打断。核心API以64位为例:atomic64_t v ATOMIC64_INIT(0); // 定义并初始化 atomic64_read(v); // 读 atomic64_set(v, 10); // 写 atomic64_inc(v); // 加1 atomic64_dec(v); // 减1 atomic64_add(5, v); // 加一个值 atomic64_sub(3, v); // 减一个值 atomic64_cmpxchg(v, old, new); // 比较并交换如果v等于old则设为new使用场景与心得场景非常适合用于简单的引用计数、状态标志位。比如内核中struct file的引用计数f_count就是一个atomic_long_t。优点开销极小通常就是一条CPU指令无需复杂的锁逻辑。坑点功能有限它只能保护这一个变量的操作是原子的。如果你需要根据这个变量的值执行一系列复杂的操作比如“如果计数为0则分配资源并加入链表”单靠原子操作是不够的因为判断和后续操作之间可能被打断。这时候需要更强的锁。内存序在多核体系下为了性能CPU和编译器会对指令重排。原子操作API如atomic64_inc_return_release提供了不同的内存序参数_relaxed,_acquire,_release,_acq_rel等用于控制重排行为。在通用驱动开发中使用默认的无后缀API通常足够安全但在实现无锁数据结构等高级场景时必须仔细考虑内存序否则会出现极其隐蔽的Bug。注意原子操作解决的是单个变量的原子性问题不解决代码块临界区的互斥问题。不要混淆。3.2 自旋锁为短临界区而生的“忙等待”锁自旋锁是内核中最常用的互斥锁之一。它的行为是当一个执行流试图获取一个已被持有的锁时它会在一个紧凑的循环中“自旋”忙等待直到锁被释放。核心API:DEFINE_SPINLOCK(my_lock); // 静态定义并初始化 spinlock_t my_lock; spin_lock_init(my_lock); // 动态初始化 spin_lock(my_lock); // 获取锁 /* 临界区 */ spin_unlock(my_lock); // 释放锁衍生变种与使用场景普通自旋锁最基础的形式。读写自旋锁(rwlock_t)允许多个读者同时进入临界区但写者必须独占。适用于“读多写少”的场景。read_lock(my_rwlock); // 读者获取锁 read_unlock(my_rwlock); write_lock(my_rwlock); // 写者获取锁 write_unlock(my_rwlock);心得即使读远多于写也要谨慎评估读者带来的缓存一致性开销。在极高并发下读写锁可能不如简单的读-拷贝-更新RCU高效。顺序锁(seqlock_t)通过一个序列计数器来实现。写者会递增序列号读者在进入和退出时检查序列号是否变化如果变化了说明读过程中有写操作需要重试。适用于“写很少但要求写者不能被阻塞”且“读者可以容忍读到稍旧数据或重试”的场景如系统时间jiffies的读取。u64 seq; do { seq read_seqbegin(my_seqlock); // ... 读操作 ... } while (read_seqretry(my_seqlock, seq));自旋锁的核心规则与“大坑”规则一持有时间必须极短。因为自旋是“忙等待”不释放CPU。如果持有锁的时间长会浪费大量CPU时间严重降低系统性能。临界区代码应该只有几十到几百条指令绝不能有耗时的操作如I/O、睡眠、大规模内存拷贝。规则二持有自旋锁时绝对不可以睡眠调用可能睡眠的函数这是内核开发的铁律。因为睡眠会导致调度器切换进程而锁还被你持有着其他在等待这个锁的CPU核心就会一直空转很可能导致死锁或系统锁死。规则三注意中断上下文。如果你在进程上下文中获得了锁而此时可能被中断打断且中断处理程序也要获取同一个锁就会导致死锁中断打断了锁持有者又试图获取同一个锁。这时需要使用spin_lock_irqsave()和spin_unlock_irqrestore()。unsigned long flags; spin_lock_irqsave(my_lock, flags); // 保存当前中断状态并禁用本地CPU中断 /* 临界区 */ spin_unlock_irqrestore(my_lock, flags); // 恢复中断状态踩坑实录早期我写一个驱动在中断处理程序里用了spin_lock在进程上下文里也用了spin_lock大部分时间没问题。但在高负载下偶尔会出现系统“卡死”。用kgdb挂上去一看一个CPU卡在中断处理程序的自旋里另一个CPU卡在进程上下文的自旋里互相等待经典的中断-进程死锁。换成spin_lock_irqsave后问题消失。3.3 信号量与互斥锁允许睡眠的“排队等待”锁当临界区操作可能耗时较长或者你需要在持有锁时睡眠自旋锁就不适用了。这时需要信号量或互斥锁。信号量一个计数器用于控制对有限数量资源的访问。down()操作减少计数如果计数为0则睡眠up()操作增加计数唤醒等待者。struct semaphore my_sem; sema_init(my_sem, 1); // 初始化为1即二值信号量用作互斥锁 if (down_interruptible(my_sem)) { // 可被信号中断的获取 // 被信号中断返回非0通常处理错误 return -ERESTARTSYS; } /* 临界区这里可以安全地睡眠 */ up(my_sem);互斥锁(mutex)这是二值信号量的优化和强化版本内核推荐用于进程上下文中的互斥。它比信号量更高效且提供了更强的调试和死锁检测功能如CONFIG_DEBUG_MUTEXES。struct mutex my_mutex; mutex_init(my_mutex); mutex_lock(my_mutex); /* 临界区这里可以安全地睡眠 */ mutex_unlock(my_mutex);选型指南与心得能用mutex就不用信号量。对于单纯的互斥场景mutex是首选它的API更清晰且内核的锁调试工具对其支持更好。信号量的适用场景当你确实需要控制“N个资源”的访问而不仅仅是互斥时。例如一个驱动有5个相同的硬件通道可以用计数为5的信号量来管理。注意事项不可用于中断上下文因为mutex_lock和down()都可能睡眠所以绝对不能在中断处理程序或持有自旋锁时使用它们。锁的持有者mutex有明确的“持有者”概念哪个任务持有它这有助于死锁检测。而信号量没有。优先级反转mutex支持优先级继承CONFIG_MUTEX_PI可以在一定程度上缓解优先级反转问题。信号量没有这个特性。3.4 完成量简单的任务间同步完成量用于一个任务等待另一个任务完成某项工作。它比信号量更轻量语义更清晰。struct completion my_comp; init_completion(my_comp); // 任务A等待完成 wait_for_completion(my_comp); // 任务B完成工作唤醒A complete(my_comp); // 唤醒一个等待者 // 或 complete_all(my_comp); // 唤醒所有等待者使用场景常用于模块初始化时等待一个内核线程启动完成或者驱动中等待一个异步的中断处理完成。它的实现底层也是基于等待队列但API更直观。3.5 读写信号量与读写自旋锁类似读写信号量允许多个读者同时持有但写者需要独占。它允许睡眠因此适用于读多写少且临界区较长的场景。struct rw_semaphore my_rwsem; init_rwsem(my_rwsem); down_read(my_rwsem); // 读者获取 /* 读临界区 */ up_read(my_rwsem); down_write(my_rwsem); // 写者获取 /* 写临界区 */ up_write(my_rwsem);心得读写信号量比读写自旋锁的开销大因为它涉及任务调度。所以只有当临界区代码确实可能睡眠或执行时间较长时才考虑用它替换读写自旋锁。3.6 RCU读侧无锁的“大杀器”RCU是Linux内核中非常精妙且高效的一种同步机制它的核心思想是读操作完全不需要锁开销极低写操作通过拷贝-更新-延迟释放的方式来保证数据一致性。工作原理简述读读者直接访问数据不需要任何锁或原子操作。它只需要在访问前后加上rcu_read_lock()和rcu_read_unlock()这仅仅是为了标记一个“读侧临界区”防止在读的过程中数据被提前释放本身不阻塞。写写者需要修改一个被RCU保护的数据结构通常是指针指向的结构时 a. 拷贝一份旧数据的副本。 b. 修改这个副本。 c. 使用一个原子操作如rcu_assign_pointer将指向旧数据的指针更新为指向新数据。这个操作完成后新的读者将看到新数据。 d. 等待一个“宽限期”Grace Period结束后确保所有在更新前就进入读侧临界区的读者都已经退出此时旧数据已无人引用再安全地释放旧数据。核心API:// 读侧 rcu_read_lock(); struct my_data *data rcu_dereference(global_ptr); // 访问 data rcu_read_unlock(); // 写侧 struct my_data *new_data kmalloc(...); struct my_data *old_data; // ... 初始化 new_data ... old_data global_ptr; rcu_assign_pointer(global_ptr, new_data); synchronize_rcu(); // 等待宽限期结束 kfree(old_data); // 安全释放旧数据适用场景与巨大优势场景读操作极其频繁写操作相对很少的网络路由表、目录项缓存dcache、各种内核哈希表等。优势读性能极高几乎零开销可以完美线性扩展读者越多总吞吐量越高。无死锁风险因为读侧根本不用锁。限制与“坑点”写者开销大synchronize_rcu()可能引起写者睡眠等待时间不确定取决于系统负载和配置。对数据结构有要求通常适用于通过指针访问的动态分配数据结构。更新必须是“发布”一个全新的版本而不是在原地修改。内存开销写操作需要额外的内存来拷贝数据。理解成本高RCU的语义和内存序模型非常复杂用错的话会导致数据损坏且极难调试。个人体会RCU是内核同步机制皇冠上的明珠威力巨大但难以驾驭。除非你处理的确实是性能瓶颈在“读”上的核心数据结构并且对内核并发有深刻理解否则建议先从简单的锁用起。很多情况下一把读写锁可能比RCU更简单、更安全。4. 实战设计一个简单的内核对象缓存管理器光说不练假把式。我们设计一个简单的内核模块用来管理一种自定义对象my_object的缓存。这个缓存需要支持并发分配和释放并且我们希望读查找操作尽可能快。4.1 需求分析与设计选型数据结构我们用一个哈希表hlist_head数组来存储对象每个对象有一个唯一的ID作为键。操作obj_lookup(id): 根据ID查找对象。这是最频繁的操作。obj_alloc(id, data): 分配并插入一个新对象。obj_free(id): 释放一个对象。并发分析lookup极频繁必须极快。alloc/free相对较少。这明显是一个读多写少的场景。同步方案选型方案A粗暴互斥对整个哈希表用一个mutex保护。简单但lookup也要抢锁性能差。方案B读写锁用rwlock_t保护整个哈希表。lookup用读锁alloc/free用写锁。性能比方案A好但写锁会阻塞所有读者。方案CRCU 每桶锁这是高性能内核代码的常见模式。哈希表本身桶数组用RCU保护允许无锁查找。每个哈希桶hlist_head用一个独立的spinlock保护用于串行化对该桶的修改操作插入、删除。因为哈希分散了冲突所以锁的争用很低。lookup使用RCU无锁遍历。alloc/free先RCU查找定位桶然后获取该桶的自旋锁进行操作最后使用RCU更新全局指针或等待宽限期后释放内存。我们选择方案C因为它能最大化读性能。4.2 核心代码实现解析#include linux/rcupdate.h #include linux/spinlock.h #include linux/slab.h #define MY_HASH_BITS 8 #define MY_HASH_SIZE (1 MY_HASH_BITS) struct my_object { int id; void *data; struct hlist_node hnode; // 用于链接到哈希桶 struct rcu_head rcu; // RCU回调头 }; struct my_cache { struct hlist_head *table; // 指向哈希桶数组的指针用RCU保护 spinlock_t bucket_locks[MY_HASH_SIZE]; }; static struct my_cache g_cache; // 哈希函数 static inline unsigned int hash_id(int id) { return hash_32(id, MY_HASH_BITS); } // 初始化 int my_cache_init(void) { g_cache.table kcalloc(MY_HASH_SIZE, sizeof(struct hlist_head), GFP_KERNEL); if (!g_cache.table) return -ENOMEM; for (int i 0; i MY_HASH_SIZE; i) { INIT_HLIST_HEAD(g_cache.table[i]); spin_lock_init(g_cache.bucket_locks[i]); } return 0; } // 查找 - RCU 无锁读 struct my_object *my_cache_lookup(int id) { struct my_object *obj NULL; unsigned int bucket hash_id(id); struct hlist_head *head; rcu_read_lock(); // 进入RCU读侧临界区 // 注意这里通过 rcu_dereference 读取 g_cache.table // 虽然在这个简单例子中 table 初始化后不会变但养成好习惯 head rcu_dereference(g_cache.table)[bucket]; hlist_for_each_entry_rcu(obj, head, hnode) { if (obj-id id) { rcu_read_unlock(); return obj; // 找到返回注意在读侧临界区外使用 } } rcu_read_unlock(); return NULL; // 未找到 } // 分配并插入 int my_cache_alloc(int id, void *data) { unsigned int bucket hash_id(id); struct my_object *new_obj, *old_obj; struct hlist_head *head; // 1. 检查是否已存在需要锁因为可能和另一个alloc并发 spin_lock(g_cache.bucket_locks[bucket]); head g_cache.table[bucket]; hlist_for_each_entry(old_obj, head, hnode) { if (old_obj-id id) { spin_unlock(g_cache.bucket_locks[bucket]); return -EEXIST; // 已存在 } } // 2. 创建新对象 new_obj kmalloc(sizeof(*new_obj), GFP_KERNEL); if (!new_obj) { spin_unlock(g_cache.bucket_locks[bucket]); return -ENOMEM; } new_obj-id id; new_obj-data data; INIT_HLIST_NODE(new_obj-hnode); // 3. 插入到哈希桶 hlist_add_head_rcu(new_obj-hnode, head); // 使用RCU版本的插入函数 spin_unlock(g_cache.bucket_locks[bucket]); return 0; } // 释放对象的RCU回调函数 static void my_cache_free_rcu(struct rcu_head *rcu) { struct my_object *obj container_of(rcu, struct my_object, rcu); kfree(obj-data); // 假设data也需要释放 kfree(obj); } // 删除 int my_cache_free(int id) { unsigned int bucket hash_id(id); struct my_object *obj NULL; struct hlist_head *head; spin_lock(g_cache.bucket_locks[bucket]); head g_cache.table[bucket]; hlist_for_each_entry(obj, head, hnode) { if (obj-id id) { hlist_del_rcu(obj-hnode); // 使用RCU版本的删除函数 spin_unlock(g_cache.bucket_locks[bucket]); // 延迟释放内存 call_rcu(obj-rcu, my_cache_free_rcu); return 0; } } spin_unlock(g_cache.bucket_locks[bucket]); return -ENOENT; }关键点解析RCU保护指针g_cache.table是一个指针它本身通过RCU保护。虽然我们这个简单例子中它初始化后不再改变但使用rcu_dereference来访问它是一个好习惯。如果未来需要动态调整哈希表大小rehash就需要用rcu_assign_pointer来更新这个指针。每桶自旋锁alloc和free操作需要修改哈希桶的链表。我们为每个桶配备一个独立的自旋锁这样不同桶上的操作可以完全并行大大减少了锁争用。RCU链表操作插入和删除链表节点时使用hlist_add_head_rcu和hlist_del_rcu。这些函数会处理好内存屏障确保在并发读的情况下读者要么看到旧链表要么看到完整的新链表不会看到中间状态。延迟释放在free操作中我们只是将节点从链表上RCU删除然后通过call_rcu注册一个回调函数。内核会在所有可能的读者都退出读侧临界区后即宽限期结束后自动调用这个回调来真正释放内存。这是RCU的精髓所在。4.3 性能考量与扩展思考这个设计在“读多写少”的场景下性能优异。lookup操作几乎是无锁的只有RCU读侧标记的开销。alloc/free操作虽然需要抢一把桶锁但由于哈希分散冲突概率低。可以进一步优化的点锁粒度如果单个桶内的对象非常多对这个桶的alloc/free操作仍然可能串行化。可以考虑使用更细粒度的锁或者使用并发性更好的数据结构如RCU保护的二叉搜索树。内存分配频繁的kmalloc和kfree可能成为瓶颈。可以考虑为my_object实现一个对象缓存slab缓存。哈希函数选择一个分布均匀的哈希函数至关重要能有效避免“热点”桶。5. 高级话题与避坑指南5.1 锁的顺序与死锁预防当你需要同时持有多个锁时死锁的风险就大大增加了。内核社区有一个简单的规则来避免死锁对所有锁定义一个全局的获取顺序任何时候都必须按照这个顺序来获取锁且不能逆序释放。例如如果你有锁A、B、C规定顺序为 A - B - C。那么任何代码需要获取其中任意几把锁时都必须按此顺序获取。即使你只需要B和C也得先获取B再获取C或者更严格地从A开始按顺序尝试获取获取不到就释放已持有的锁重试。内核的lockdep子系统CONFIG_PROVE_LOCKING是一个强大的死锁检测工具。它会在运行时跟踪锁的获取顺序如果发现违反规则的可能就会抛出警告。在开发阶段务必打开这个选项进行测试。踩坑实录我曾维护一个驱动需要同时获取一个设备锁和一个全局链表锁。代码中有一处先拿设备锁再拿链表锁另一处在中断处理程序中先拿链表锁再尝试拿设备锁。在单处理器或低负载下相安无事。一旦SMP环境高负载运行死锁必然发生。lockdep立刻抓住了这个错误。修复方法就是统一锁序中断处理程序也按“设备锁-链表锁”的顺序获取如果拿不到链表锁就放弃并返回重试。5.2 预防优先级反转优先级反转发生在低优先级任务持有高优先级任务所需的锁而中优先级的任务又抢占了低优先级任务导致高优先级任务间接被中优先级任务阻塞。内核的解决方案互斥锁的优先级继承(CONFIG_MUTEX_PI)当高优先级任务等待一个被低优先级任务持有的mutex时内核会临时将低优先级任务的优先级提升到与高优先级任务相同让它尽快执行完释放锁从而减少高优先级任务的阻塞时间。实时互斥锁(rt_mutex)在实时内核 (CONFIG_PREEMPT_RT) 中rt_mutex提供了更严格的优先级继承和死锁避免机制。对于驱动开发者如果你的代码可能用在实时系统或对延迟敏感的环境中使用mutex并启用PI支持是一个好习惯。5.3 无锁编程与内存屏障RCU是一种高级的无锁编程范式。更底层的无锁编程通常直接使用原子操作和内存屏障。内存屏障它告诉编译器和CPU“在这个屏障之前的所有内存操作必须在这个屏障之后的所有内存操作之前完成”。这对于在多核系统上实现正确的无锁算法至关重要。smp_mb(): 通用内存屏障。smp_wmb(): 写内存屏障保证屏障前的写操作先于屏障后的写操作提交。smp_rmb(): 读内存屏障保证屏障前的读操作先于屏障后的读操作完成。一个经典例子——自旋锁的实现// 简化版自旋锁获取 void spin_lock(spinlock_t *lock) { while (atomic_cmpxchg(lock-val, 0, 1) ! 0) { // 尝试将0换成1 while (atomic_read(lock-val) ! 0) // 忙等待 cpu_relax(); } smp_mb(); // 获取锁后加一个全屏障保证临界区内的读操作不会重排到锁外 }atomic_cmpxchg本身包含内存屏障语义。最后的smp_mb()是为了保证“获取锁”这个动作与进入临界区内的内存操作之间的顺序。忠告除非你是内核核心代码的开发者或者有极致的性能需求否则尽量不要自己用原子操作和内存屏障去实现复杂的无锁数据结构。直接使用内核提供的成熟同步原语spinlock,mutex,rcu要安全得多。自己实现的无锁代码其正确性验证极其困难。5.4 调试技巧与常用工具Lockdep(CONFIG_PROVE_LOCKING)如前所述死锁检测神器。任何锁顺序问题都逃不过它的法眼。开发阶段必开。Lock Stat(CONFIG_LOCK_STAT)统计锁的争用情况。可以告诉你哪个锁被争用得最厉害持有时间最长是性能调优的重要工具。Debug Lockups(CONFIG_DEBUG_LOCK_ALLOC,CONFIG_DEBUG_SPINLOCK,CONFIG_DEBUG_MUTEXES)这些调试选项能帮你发现未初始化的锁、在错误上下文中使用锁如在中断中用mutex、以及释放一个未持有的锁等问题。KCSAN (Kernel Concurrency Sanitizer)(CONFIG_KCSAN)这是一个数据竞争检测器。它能发现那些你忘了加锁保护的共享数据访问对于找出潜在的竞态条件非常有帮助。内核跟踪器ftrace和perf可以跟踪函数调用和调度事件结合分析可以帮助你理解锁争用发生的调用路径。排查锁争用问题的基本思路系统变慢使用top或perf发现某个CPU使用率100%且主要在用户态 (us或sy高)。使用perf record -g -a采样然后perf report查看热点函数。如果看到spin_lock、_raw_spin_lock、queued_spin_lock_slowpath等函数占用大量时间说明存在严重的锁争用。使用lock_stat查看具体是哪个锁的问题。分析代码看能否缩小锁的粒度把一把大锁拆成多把小锁减少持有锁的时间或者改用读写锁、RCU等更适合的同步机制。内核同步是Linux内核开发的深水区它要求开发者对硬件架构、内存模型、编译器行为都有一定的理解。最好的学习方式就是阅读优秀的内核代码如网络栈、文件系统看看大神们是如何在复杂性和性能之间取得平衡的。同时勤用调试工具在代码中谨慎加锁多思考“这个锁真的需要吗有没有更优的方案”这样才能写出既正确又高效的内核代码。
)
