Lenky个人站点

在Linux系统里，假设有两处代码（比如不同线程的两个函数F1和F2）都要获取两个锁（分别为L1和L2），如果F1持有L1后再去获取L2，而此时恰好由F2持有L2且它也正在尝试获取L1，那么此时就是处于死锁的状态，这是一个最简单的死锁例子，也即所谓的AB-BA死锁。

说一下上文中最开始提到的“某个问题”：如果一台主机网卡比较多，然后每个网卡分队列又比较多，总之结果就是系统里的网卡设备的中断号比较多（关于超过256个中断数的情况，请见参考1，2，3），一旦所有这些中断都绑定到同一个CPU，那么如果网卡收到数据包进而触发中断，而众多硬中断一嵌套就非常容易出现中断栈溢出。一旦中断栈溢出，那么将会导致怎样的结果，这曾在之前的文章里隐含的提到过，这里再重新整理一遍。

对于x86硬中断的概念，一直都落在理论的认识之上，直到这两天才（因某个问题）发现Linux的实现却并非如此，这里纠正一下（注意：Linux内核源码更新太快，一个说法的时效性太短，所以需注意我提到的香草内核版本，并且以x86-64架构为基准）。

不得不说printk()函数是一个伟大的调试工具，它几乎能帮助我们在Linux系统的任何位置把我们想要的数据打印出来，但同时这也是一个比较耗时的过程，因为我们得把printk()函数加入到Linux内核源码的对应位置，重新编译模块，如果是内核修改，那么也许还得重启机器。

已有各种工具可以帮助我们调试内核，比如UML、kgdb、qemu等，但比较麻烦的是gdb经常给我一个“value optimized out”的提示，而且执行的路径与gdb的显示也不对应，最近我在利用UML调试ext3文件系统的逻辑时就为此而感到非常麻烦（2.6.30.8的内核）：

SO_LINGER是nginx里用到的另外一个重要套接口选项（因为它涉及到的问题很重要），虽然它不是特定于TCP套接口的，但针对的仍然是面向连接的协议，因此就TCP而言，自然也是可以使用它，这里就统一以TCP为例（即下面所提到的套接口仍然都还是TCP套接口）来进行阐述。

学过计算机网络课程的人，应该都知道TCP协议有个连接状态转换图，也许对其整体详细不甚清楚，但至少对TCP握手协议有些印象。标准的TCP三次握手（本节仅考虑这种情况，对于四次握手等其他情况，可以参考RFC 793和http://lenky.info/?p=1921）的一般图示如下：

从上一节的内容可以看到，选项TCP_NODELAY是禁用Nagle算法，即数据包立即发送出去，而选项TCP_CORK与此相反，可以认为它是Nagle算法的进一步增强，即阻塞数据包发送，具体点说就是：TCP_CORK选项的功能类似于在发送数据管道出口处插入一个“塞子”，使得发送数据全部被阻塞，直到取消TCP_CORK选项（即拔去塞子）或被阻塞数据长度已超过MSS才将其发送出去。举个对比示例，比如收到接收端的ACK确认后，Nagle算法可以让当前待发送数据包发送出去，即便它的当前长度仍然不够一个MSS，但选项TCP_CORK则会要求继续等待，这在前面的tcp_nagle_check()函数分析时已提到这一点，即如果包数据长度小于当前MSS &&（（加塞 || …）|| …），那么缓存数据而不立即发送：

在网络拥塞控制领域，我们知道有一个非常有名的算法叫做Nagle算法（Nagle algorithm），这是使用它的发明人John Nagle的名字来命名的，John Nagle在1984年首次用这个算法来尝试解决福特汽车公司的网络拥塞问题（RFC 896），该问题的具体描述是：如果我们的应用程序一次产生1个字节的数据，而这个1个字节数据又以网络数据包的形式发送到远端服务器，那么就很容易导致网络由于太多的数据包而过载。比如，当用户使用Telnet连接到远程服务器时，每一次击键操作就会产生1个字节数据，进而发送出去一个数据包，所以，在典型情况下，传送一个只拥有1个字节有效数据的数据包，却要发费40个字节长包头（即ip头20字节+tcp头20字节）的额外开销，这种有效载荷（payload）利用率极其低下的情况被统称之为愚蠢窗口症候群（Silly Window Syndrome）。可以看到，这种情况对于轻负载的网络来说，可能还可以接受，但是对于重负载的网络而言，就极有可能承载不了而轻易的发生拥塞瘫痪。

最近在公司看Linux内核的nmi死锁检测功能的实现机制，当然，是因为它变了，所以我才看的，简单来说就是在红帽的某牛提交了一个内核patch：new nmi_watchdog using perf events，这个patch已经被合入到内核主线2.6.38版本，所以使用自该版本开始后内核的Linux系统，其/proc/interrupts显示的中断数不再按每秒1000次的频率增长。关于new nmi_watchdog问题，本文不再多说，后续写专篇文章，下面看使用systemtap调试Linux内核的几个案例，因为我最近就是通过这个手段来理解new nmi_watchdog的实现机制，相比利用printk或kgdb而言，使用systemtap更为简单方便，效率也大大提高。

翻内核代码，看到几个有意思的东东，然后Stackoverflow查了一把BUILD_BUG_ON（不知从何时起，我遇到问题都是先Stackoverflow，找不到再Google，也许是因为在Stackoverflow里，如果能找到答案，那么答案会更明确&详细吧），于是有此文章。

在Linux内核里无法直接进行浮点计算，这是从性能上的考虑，因为这样做可以省去在用户态与内核态之间进行切换时保存/恢复浮点寄存器 FPU的操作，当然，这到底可以提升多少性能我还不得而知，不过就目前而言，Linux内核的确就是这样做的。