我编写的代码很少创建/删除对象（最多数千个），但在软 IRQ 上下文中非常频繁地修改它们。这些对象也很少从任务上下文中读取（并且可能也很少被修改）（通过 procfs：每个对象的文件）。目前我的代码包含全局的 per-CPU 数据块，每个数据块都由一个自旋锁保护。这样的块包含用于对象存储的固定大小的哈希表。
显然，当前的设计不是最优的，尤其是在对象更新负载非常高的情况下：从 procfs 读取对象会导致更新软 IRQ 时数据丢失。我需要重写同步方案以摆脱全局锁。最明显的选择 - 为每个哈希表存储桶设置一个自旋锁 - 它应该可以很好地扩展。问题是我可能需要使用我自己的哈希表实现，或者至少重新实现几个顶级宏（在 linux/hashtable.h 中没有找到那些用于自旋锁保护的存储桶）。我是否也应该考虑启用 RCU 的哈希表（但我对这种同步方法没有深入的了解）？
带有锁保护的桶在头文件linux/list_bl.h中声明。他们使用头指针的最低位作为锁定位。
RCU 保护的对存储桶的访问由头文件linux/hashtable.h中的其他哈希表函数定义（它们有_rcu后缀）。
在锁和 RCU 之间进行选择取决于您。请注意，RCU 本身无法解决修改-修改冲突。它主要用于经常读取的数据，这似乎不是你的情况。
hlist_bl_lock由于只为 声明了一个锁定函数 - -struct hlist_bl_head并且该函数不知道 irq 的，所以当哈希表可以用于 irq 或下半部分时，应该执行额外的操作：
spin_lock_irqsave：
local_irq_save(flags);
hlist_bl_lock(...);
spin_unlock_irqrestore：
hlist_bl_unlock(...);
local_irq_restore(flags);
spin_lock_bh：
local_bh_disable();
hlist_bl_lock(...);
spin_unlock_bh：
hlist_bl_unlock(...);
local_bh_enable();