查一个问题：结果看了一下软中断以及系统 所耗cpu，心中满是伤痕啊-------
perf 结果一眼可以看到:主要是锁
那么这个lock 是用来干什么的呢？？
A:TCP socket的使用者有两种：进程（线程）和软中断。同一时间可能会有两个进程（线程），或位于不同CPU的两个软中断，或进程（线程）与软中断访问同一个socket。所以为了使socket在同一时刻只能被一个使用者访问，那么互斥机制是如何实现的呢？----是使用锁完成的， 也就是这个锁lock sock
struct sock { ... socket_lock_t sk_lock; ... } /* This is the per-socket lock. The spinlock provides a synchronization * between user contexts and software interrupt processing, whereas the * mini-semaphore synchronizes multiple users amongst themselves. */ typedef struct { spinlock_t slock;//该自旋锁是用于同步进程上下文和软中断上下文的关键； int owned;//取值为1表示该传输控制块已经被进程上下文锁定，取值为0表示没有被进程上下文锁定； wait_queue_head_t wq;//wq：等待队列，当进程上下文需要持有该传输控制块，但是其当前又被软中断锁定时，进程会等待 /* * We express the mutex-alike socket_lock semantics * to the lock validator by explicitly managing * the slock as a lock variant (in addition to * the slock itself): */ #ifdef CONFIG_DEBUG_LOCK_ALLOC struct lockdep_map dep_map; #endif } socket_lock_t;
进程上下文的访问操作
进程上下文在访问该传输控制块之前需要调用lock_sock()锁定，在访问完成后调用release_sock()将其释放
//__lock_sock()将进程挂到sk->sk_lock中的等待队列wq上，直到没有进程再持有该该传输 //控制块时返回。注意：调用时已经持有sk->sk_lock，睡眠之前释放锁，返回前再次持有锁 static void __lock_sock(struct sock *sk) { //定义一个等待队列结点 DEFINE_WAIT(wait); //循环，直到sock_owned_by_user()返回0才结束 for (;;) { //将调用进程挂接到锁的等待队列中 prepare_to_wait_exclusive(&sk->sk_lock.wq, &wait, TASK_UNINTERRUPTIBLE); //释放锁并打开下半部 spin_unlock_bh(&sk->sk_lock.slock); //执行一次调度 schedule(); //再次被调度到时会回到这里，首先持锁并关闭下半部 spin_lock_bh(&sk->sk_lock.slock); //如果没有进程再次持有该传输控制块，那么返回 if (!sock_owned_by_user(sk)) break; } finish_wait(&sk->sk_lock.wq, &wait); } void lock_sock_nested(struct sock *sk, int subclass) { might_sleep();//调用lock_sock()可能会导致休眠---------注意 spin_lock_bh(&sk->sk_lock.slock);//持有自旋锁并关闭下半部 //如果owned不为0，说明有进程持有该传输控制块，调用__lock_sock()等待，挂在等待队列上休眠 if (sk->sk_lock.owned) __lock_sock(sk); //上面__lock_sock()返回后现场已经被还原，即持有锁并且已经关闭下半部。 //将owned设置为1，表示本进程现在持有该传输控制块 sk->sk_lock.owned = 1; //释放锁但是没有开启下半部-----还是关闭了 软中断 spin_unlock(&sk->sk_lock.slock); /* * The sk_lock has mutex_lock() semantics here:------------这是干啥？
We express the mutex-alike socket_lock semanticsto the lock validator by explicitly managingthe slock as a lock variant
(in addition tothe slock itself): ------不懂*/
mutex_acquire(&sk->sk_lock.dep_map, subclass, 0, _RET_IP_); local_bh_enable();//开启下半部 软中断 }
owned为1之后不再持有自旋锁，也已经开启软中断。-----作用是协议栈的处理并非立刻就能结束，如果只是简单的在开始起持有自旋锁并关闭下半部，在处理结束时释放自旋锁并打开下半部，会降低系统性能，同时长时间关闭软中断，还可能使得网卡接收软中断得不到及时调用，导致丢包
release_sock()
进程上下文在结束传输控制块的操作之后，需要调用release_sock()释放传输控制块。释放的核心是将owned设置为0并通知其它等待该传输控制块的进程
void release_sock(struct sock *sk) { /* * The sk_lock has mutex_unlock() semantics: */ //调试相关，忽略 mutex_release(&sk->sk_lock.dep_map, 1, _RET_IP_); //获取自旋锁并关闭下半部 spin_lock_bh(&sk->sk_lock.slock); //如果后备队列不为空，则调用__release_sock()处理后备队列中的数据包，见数据包的接收过程 if (sk->sk_backlog.tail) __release_sock(sk); //设置owned为0，表示调用者不再持有该传输控制块 sk->sk_lock.owned = 0; //如果等待队列不为空，则唤醒这些等待的进程 if (waitqueue_active(&sk->sk_lock.wq)) wake_up(&sk->sk_lock.wq); //释放自旋锁并开启下半部 spin_unlock_bh(&sk->sk_lock.slock); }
（1）软中断先访问进程后访问
这时软中断已经获取了自旋锁，进程在获取自旋锁时会等待，软中断释放锁时进程才能成功获取锁。
（2）进程先访问软中断后访问
进程获取自旋锁（关软中断，防止被软中断打断）时会将sk->sk_lock.owned设置为1后释放自旋锁并开启软中断，然后执行对socket的访问。这时如果软中断发生，则进程的执行被中止，然后软中断中 将数据放到接收后备队列中
int tcp_v4_rcv(struct sk_buff *skb) { ... process: ... //获取sk->sk_lock.slock自旋锁 bh_lock_sock_nested(sk); //如果没有进程锁定该传输控制块，将数据接收到奥prequeue或者receive_queue中 if (!sock_owned_by_user(sk)) { if (!tcp_prequeue(sk, skb)) ret = tcp_v4_do_rcv(sk, skb); } else //如果进程已经锁定该传输控制块，那么先将数据接收到后备队列中----赶紧退出 让进程处理 然后在release的时候 处理后备队列 sk_add_backlog(sk, skb); //释放自旋锁 bh_unlock_sock(sk); ... /* BH context may only use the following locking interface. */ #define bh_lock_sock(__sk) spin_lock(&((__sk)->sk_lock.slock)) #define bh_lock_sock_nested(__sk) spin_lock_nested(&((__sk)->sk_lock.slock), SINGLE_DEPTH_NESTING) #define bh_unlock_sock(__sk) spin_unlock(&((__sk)->sk_lock.slock))
所以这个锁 貌似 规避不了，那么怎么处理呢？？？