讨论一下 nf_conntrack 表的锁

Godbach

代码中整个 conntrack 表就是用一个全局的锁 nf_conntrack_lock， 内核版本是2.6.24。
如果在多核下，按理说会影响并发访问的性能啊

funix_zjx

这个锁用的地方很少，影响应该不大

Godbach

这个锁用的地方很少，影响应该不大
funix_zjx 发表于 2010-11-17 11:08

整个 conntrack 模块在操作 conntrack 时都需要适用这个所，怎么理解你说的用的地方很少呢

funix_zjx

并不是每次操作conntrack的都需要这个锁，你搜索一下代码就知道了。

Godbach

多谢。

我看了一下代码，基本上 conntrack 的查找、添加和删除都是需要加锁的。

如果有两个并发的删除动作，按照已有的实现方式，肯定是需要先后顺序进行的，对吧。

瀚海书香

回复 5# Godbach
应该是。
每当cat /proc/net/ip_conntrack的时候，如果连接过多，那么系统的网络应用会明显变慢。

Godbach

应该是。
每当cat /proc/net/ip_conntrack的时候，如果连接过多，那么系统的网络应用会明显变慢。

我当前看的 2.6.24 的内核是使用的读写锁，据说最新的内核又改成了 spinlock。

对了，cat /proc/net/ip_conntrack 这个动作，内核的实现使用 seq_file, 不知道这方面你了解吗。

瀚海书香

回复 7# Godbach
了解。
cat的时候的确有个copy_to_user的过程，但在我感觉慢应该是锁的原因，应该不是seq_file的原因。

Godbach

这里有有这样一个问题，我现在 2.6.24 的源码中看到在向用户空间输出 conntrack 信息的时候：

1. static void *ct_seq_start(struct seq_file *seq, loff_t *pos)
   
2. {
   
3.         read_lock_bh(&nf_conntrack_lock);
   
4.         return ct_get_idx(seq, *pos);
   
5. }
   
6. 
   
7. 
   
8. static void ct_seq_stop(struct seq_file *s, void *v)
   
9. {
   
10.         read_unlock_bh(&nf_conntrack_lock);
    
11. }

复制代码

在 start 和 stop 进行了加锁和解锁，而 seq_read 的实现中是有 copy_to_user 调用的，这个调用有可能引起 sleep。这个 sleep 对读写锁没有影响吧，如果使用 spinlock 的话，内核就会抱怨。

因此，最新内核的 conntrack 在使用 spinlock 作为全局锁之后，其对应的 seq_start 和 seq_stop 实现改变了：

  92static void *ct_seq_start(struct seq_file *seq, loff_t *pos)
  93        __acquires(RCU)
  94{
  95        rcu_read_lock();
  96        return ct_get_idx(seq, *pos);
  97}
  98
  99static void *ct_seq_next(struct seq_file *s, void *v, loff_t *pos)
100{
101        (*pos)++;
102        return ct_get_next(s, v);
103}
104
105static void ct_seq_stop(struct seq_file *s, void *v)
106        __releases(RCU)
107{
108        rcu_read_unlock();
109}

改成使用 rcu 了。

瀚海书香

回复 9# Godbach
哦。最新的内核该成这样的了
感觉rwlock就挺好啊。改成spinlock和rcu来实现，效率有什么大的提升吗？