春节放假回家这段时间，N770充分发挥了它作为电子图书阅读器的功能，它让我避免了携带厚如砖头、重如石块的计算机图书的麻烦，用它我看了好多章节的《》。收获还是颇丰的，至少这本书的写作风格还是挺符合我的口味的，如果手头再有源码可以对照的话，可能就更加完美了。
这段时间还是累积了大量的RSS文章，打开google reader，竟然多达上千篇，有选择地浏览了一下，至于杂质比较多的源为了节省时间，就直接标记所有文章为已读了。确实，这段时间也没有发生太多事情。依稀记得的可能就是一些已经发生的并购案：Sun收购了Virtual Box和Mysql，NOKIA收购了QT，还有就是闹得沸沸扬扬、至今还没有结论的Microsoft对Yahoo的并购案。隐约觉的IT行业的不景气可能再次开始，有的朋友可能已经为了涨薪的事情闹得很不开心了。
春节回来到现在一直为了公司产品的发布而忙碌着，几乎没有时间为自己注入新鲜的精神血液。直到今天才得以空闲，可以肆无忌惮地睡眠。醒来后，依旧头晕脑涨，迷迷糊糊的。竟然感觉有些无所事事，抄起N770随便翻着，才发现原来我落下了以前总是定期查看的LWN没有理睬。就开始咀嚼上面贴的关于Linux内核的文章，里面的东西还真的很让人激动、很提神。下面我就简单谈谈其中几个自己比较感兴趣的部分：
继和之后，能提高内核实时性能的也被加入了Linux-2.6.25-RC1。处于经典RCU的读临界区的进程是不能被抢占的，事实上在可强制抢占的内核中，rcu_read_lock/rcu_read_unlock只是简单地通过调用preempt_disable/preempt_enable来禁止和打开抢占，这意味着一个高优先级的进程可能被阻塞，而得不到及时的调度，即优先级反转，增加系统的响应时间。可强占RCU就是为了解决这个问题才被发明出来，它取消了读临界区不可抢占这一限制，但是需要注意，处于可抢占RCU读临界区的进程仍然是不允许睡眠的，也就是说不能在其中明确或者是隐含调用schedule，如果有上述需求，应该采用可休眠RCU。翻了一下内核，发现已经悄悄地在某个内核版本中被加了进去。
虽然在Linux-2.6.17中，和系统调用作为高性能API就被引入了Linux内核，但是对socket的splice读操作却由于某些原因迟迟未能并入Linux内核。为此，我也详细地研究了相关的，本打算找个时间实现一个玩玩，不过从目前来看，应该是没有这个必要了：2.6.25-RC1中已经收录了相关。通过git的web接口大致浏览了一下，感觉和我过的一种实现类似，并且发现它可能还是有些问题的，留作下周一去详细研究下，希望我是错的，并且很有可能！
最让我惊奇的应该就是当前x86内核中自旋锁（spinlock）的了，如此精巧的设计，相信你也会叹服的，原文很好，我也就不罗唆了！
在Linux内核的开发过程中，panic有的时候是再所难免的。因为linus总是认为一个好的错误消息比集成一个面向开发者的笨重的内核调试器更加有效，所以到目前为止Linux内核还没有一个内建的调试器可用，虽然第三方补丁（如kdb，kgdb）一直存在，并且kgdb已经为进入官方内核而做了很多工作，希望以后的情形会有所改变。错误消息成为了发现内核bug的几乎唯一简单（基于kexec的kdump也显得笨重）途径，虽然2.6内核内建了kallsyms，不再需要其他工具就能简单地读懂Oops消息了，但是因为屏幕大小有限而吐出的消息通常又很长，且panic的时候键盘通常不可用，所以回滚也只是成了摆设。就是使得panic的时候键盘依然有效，开发者可以通过回滚的方式来查阅冗长的Oops信息。实际上，还有另外一种办法：通过将内核的启动参数console设置成ttyS0，把Oops消息通过串口导出到文件，这样就能看到完整的Oops消息了。当然，你也可以发挥一下，利用netconsole通过网络把Oops消息发送到其它计算机。
新的内核状态TASK_KILLABLE在2.6.15中被引入，不同于TASK_UNINTERRUPTIBLE，处于TASK_KILLABLE状态的进程是可以被致命信号（如SIGKILL)唤醒的，实际上目前内核中很多地方的TASK_UNINTERRUPTIBILE都可以替换成TASK_KILLABLE，这样处于“D”状态的不能杀死的进程也许就不会，至少是很少出现了。
拿什么来结束呢？也许根本就没有结束！
阅读(2296) | 评论(0) | 转发(0) |
