Kernel Summit 2013会议记录

Kernel Summit是内核社区最重要的线下社区，采用邀请制，参会人数控制在80人。会议本身主要讨论开发流程问题，尽量不讨论具体的技术问题，即使讨论，也会挑选众人都可以参与的话题。

 

这两年会议的日程有所变化。现在会议分三天进行，第一天是纯粹的mini summit，第二天只有core developers参与，第三天的会议之前参与mini summit的人员也会一起参与。

 

 

 

以下是今年Kernel Summit的主要议题和相关总结：

Defining Kernel Interfaces: Boundary Between Userspace And Kernel (Peter Anvin / Miklos Szeredi)

 

这个话题是由一个事情引起的，Grub2将kernel config当作kernel ABI使用，导致当内核更改config时，grub2就挂了。Linus在会上明确说了这完全是grub2的问题。

 

内核提供的最纯正的ABI是系统调用，对系统调用的兼容性是必须保证的，所以往内核添加系统调用是非常困难的。但内核有越来越多的用户可见的接口，例如procfs、sysfs、debugfs、cgroupfs、ioctl、sysctl等等，有些是否是Kernel ABI显得有些不太清楚，例如tracepoint就是最常见的争议。还有printk所输出的信息也被一些应用程序所使用，因此也有人试图标准化printk。

OPW Mentorship program (Sarah Sharp)

帮忙女性参与开源社区的一个项目，内核也在其中，基本上有些政治和社会意义，跟我们完全无关。

Cgroups

 

目前正在进行的cgroup refactor/redesign，一直有比较多的争议，因为这将改变kernel ABI，影响到当前cgroup的上层用户，例如Google、Libvirt等等。

 

Cgroup最大的变化是做成unified hierarchy，以及不允许per-thread操作。Cgroup消息通知机制目前有usermodehelper和eventfd，都将会被更好的机制所替代，还有所有子系统都会支持hierarchy。

 

这样做的原因是，cgroup发展到现在，大家发现一直以来cgroup缺乏比较好的控制，现在变得有些混乱，产生大大小小的问题。例如multiple-hierarchy导致各个cgroup subsystem都不能有所交集从而做到一些优化和一致性、不同的cgroup用户在同时使用cgroup时往往会遇到各种麻烦……

 

现在已经跟Google等通过讨论达到一些共识，Google愿意接受unified-hierarchy的方案，而内核也会为cpu cgroup支持一定程度的per-thread特性。但内核社区最终是必须用代码说话的，实现出来后很可能还会有争议。

 

目前我司使用cgroup的产品也越来越多，为了避免以后出现兼容性问题，应该对这些改变有所了解，并尽量采用内核社区的推荐使用方法，对于我们合理的需求，也可以在社区中发出我们的声音，甚至让社区尊重和考虑我们的需求。

Linux-next tree (Stephen Rothwell)

 

Linux-next从2008年开始动作。没有linux-next时，我们没法保证将各个maintainer的开发分支合并在一起后，内核还能否编译和正常启动、运行。

 

Stephen说还是有10%的代码没有进入linux-next就直接在merge window期间进入内核主线了，但他认为这种情况不会有改观。另外，有些代码在merge window前才匆匆忙忙进入linux-next，在next里只待了一两个星期就合入主线。

Stable tree maintenance

 

Stable tree总体来说是运作得比较好的，虽然总是难免有些主线的bug fix在stable tree中遗漏。

 

会上言论了一些问题。一个是，patch从主线合入stable的速度太快了，这些bug fix本身也可能是有bug的，从而影响stable的质量。目前Greg的调整也就是等patch在主线多待几天再合入。

 

Greg通过多年的努力才让大家普遍了解和接受stable的运作，但他提到仍然有些maintainer显得不大合作。另一个问题是，有些bug fix在linux-next中待太久，而没有即时进入主线，也就是没能即时进入stable。

另一个问题是，在众多发行版中，只有Debian和Fedora是积极的将bug fix反馈到stable的。由于发行版有众多的实际用户，这期间发现的bug及相应的bug fix是非常有价值的。

KS期间我也跟Greg交流了，让他了解了我们在stable社区做的工作。到目前为止，我们已经向3.4 stable反馈了数十个bug fix了。

kernel testing (Fengguan Wu, David Jones)

 

这一两年内核出现了两个测试利器，一个是0day testing，另一个是Trinity。

 

Intel OTC早先就有一个测试框架用来大概每个linux内核RC版都跑一系列benchmark，并且向社区汇报发现的性能退化。峰光接手这个工作后，深感这个测试框架不行，于是重新做了一个。

 

0day每个小时都会将各个内核开发分支合并，然后做各类编译测试、静态代码检查、启动测试、性能测试等，并且在发现问题后能自动做git-bisect，最后自动将bug发到内核社区。

 

峰光说0day以前每天汇报20个bug，现在只有10个了，估计是maintainer们更主动的用工具扫描自己的代码了。

 

0day是将各个现有的测试工具集成到他的测试框架中，而Trinity则是一个独立的测试工具。Trinity的测试方法是对各个系统调用喂随机的参数值，但是这些随机的值又是经过一定的设计的，从而避免系统调用直接返回EINVAL等错误码，从而大大提高了测试的有效性。

 

Trinity已经发现了很多的内核bug了，往往是触发kernel warning甚至是bug_on、空指针引用等严重问题。

 

Trinity的一个缺陷是，由于它是不停的随机并发的跑各个系统调用，当内核crash时，我们不一定知道这个crash产生的真正原因。但这个问题看来没什么办法。

New kernel subsystems: Are we being too lax?

 

Christoph提到他的一个感受是，现在我们对内核新特性的合入似乎太宽松太随意了，似乎有些maintainer是什么都合入，有些则是对什么都不理不睬。我们对自己领域外的代码和特性的review和关注越来越少了。

 

这就像社会发展导致的分工越来越细一样，内核现在越来越庞大，内核社区也越来越宠大，各人的知识技能都越来越难跨领域，精力本身也有所不及。

 

而另一个原因则是，以前的Linux内核还处在追赶其他操作系统的阶段，那时候的新特性常常是其他操作系统已有的，review也就有了参照物，而现在Linux内核已经走在了其他操作系统的前面，这样就只能自己摸着石头过河了。

 

Linus提出可以创建一个新的邮件列表，把参加Kernel Summit的人都强制加进去，大家可以把希望得到core developer关注的东西发到这里面来。Linus开玩笑的说，谁不乐意以后就不要再来Kernel Summit了。会后这个邮件列表就真的有了，不过到目前为止完全没有起到预期的作用——就没人往那里发邮件。

ARM readout

 

ARM mini summit的总结，主要提到了single zImage和Device Tree的问题。总结说对于DT的Kernel ABI的保证，一方面通过加强review过程，一方面通过引入版本号来解决。但DT的争议肯定还会继续。

 

Power-aware scheduling readout

 

问题：终端设备流行，对节能有很高的要求，bit.LITTLE的出现，等等。cpuidle、cpufreq等跟scheduler分开，scheduler在节省方面做的不好。内核社区出现大量实现节能调度的patchset：task packing等…
怎样衡量系统的能耗情况？？
结论：先要有一个相关的benchmark；将cpuidle合入scheduler、cpufreq则应该被抛弃；
道路还很漫长…

Scalability talks (Paul McKenney、Andi Kleen等)

 

这里比较值得关注的是Andi讲的用transactional memory实现Lock Ellision。

 

目前Intel的Haswell支持TSX了，由TSX可以实现锁的优化，不管是内核里的锁还是用户态的。

 

Andi发过一个patchset，将TSX的支持加到spinlock里，但是他没有提供性能数据，所以也没有被主线所接受。Linus认为在一些场景下lock ellision反而会导致性能下降，Andi认为不会。但是在没有数据的情况下，这样纸上谈兵很难有说服力。

Security (Kees Cook)

 

Kees是Google的，在Google内的工作是ChromeOS，他很关注安全领域。

 

Kees称自己很容易在内核代码里发现各种安全漏洞，例如printk(buffer)这种。Kees建议不要去跟踪CVE，而是直接升级stable版本。

 

对于内核来说，基本上都是社区发现bug并及时修复bug ，过后才会有人认为某些bug属于安全漏洞，然后为那些bug申请CVE号。而社区在修复bug的时候，很可能是没有意识到或者太在意它是个安全漏洞的，所以stable tree里有很多bug虽然属于安全漏洞，但是并没有记录在CVE里。

 

我们自己在分析CVE时，只发现过两例没有合入3.4内核的CVE漏洞修复。

 

会上提出在Changelog里，对于bug fix的话，加上一行”Fix: XXX”，表示该patch修复了由XXX这个commit引入的bug。但我基本上从来没有见过有人这样做过，这样的做法如果能实施起来，对stable的质量是挺有帮助的，但是目前没有谁在积极的推广这样做。

Kernel.org infrastructure (Konstantin Ruyabitsev)

 

Kernel.org是存放Linux内核源码的地方，管理员讲了现在kernel.org的情况，包括怎样保证数据不丢失等。然后提到在一些地方会先后建立git mirror，包括我们国内也会有，这样国内拉git tree应该会快得多。

。