Linux Kernel峰会（简称KS）是Linux最重要的年度大会，受邀的是开源组织各个子系统的维护者和核心开发者。今年的峰会安排在10月23-25日。作为Google内核开发组和Linux开源开发的一员，作者受邀参加了今年的KS大会。文中记录了一些印象较深的讨论。

What’s Next For Control Cgroup

Cgroup是内核里用来把用户进程分组的机制。

在此基础上每个子系统（CPU、Memory、Disk和Networking）有相应的机制来监控和限制资源利用。用cgroup和resource controller来实现多个任务的资源共享，同时提供每个任务运行环境的隔离，从而保证任务性能的稳定性。由于与现有的Virtual Machine在系统性能上保有优势，包括RedHat、openSUSE、Google、IBM、Oracle和Parallel等在内的公司都在一定程度上采用了cgroup。

由于越来越多的用户需求，今年KS上专门安排了有关cgroup的讨论。James Bottomley首先提出了目前cgroup开发社区资源不足的问题，包括开发人员和维护者。现有维护者由于某些原因即将退出，大家一致认为需要马上找到新的维护者。Andrew Morton指出很多在内存管理社区的patch都是和cgroup相关的，现在的问题是没有专门的cgroup开发人员参与讨论和做Code Review，相应的patch进度就会被放慢。当然，同样的问题在其他子系统里也会出现。James在会后创建了一个新的邮件列表（cgroups@vger.kernel.org)，除了针对cgroup的讨论外，所有子系统的controller的讨论也建议抄送到这个列表上。不管cgroup现有的实现是否理想，但用途已经越来越广。包括Andrew和Linus都在会上提到cgroup的发展是不可逆转的，接下来也希望多一些社区开发者加入到其中的讨论中。

Memory Controller（memcg） Workshop

Memcg建立在cgroup的基础上，支持memory isolation机制。这次难得的机会，很多核心开发人员包括维护者都来到了布拉格，所以在LinuxCon会议期间我们组织了个专门的Workshop。包括来自Google、RedHat、openSUSE、Fujitsu和OpenVZ的十几位工程师在一起讨论了当前的开发进度和之后的开发计划。这次的Workshop我们主要针对最近的几个开发项目进行了讨论，这里简单介绍一下几个重点项目。

• Kernel Memory Accounting：目前3.1内核中memcg只支持user page accounting，但由于用户进程也会申请大量kernel memory，没有相关的kernel memory accounting会严重影响程序运行性能的稳定性。Google和OpenVZ都在参与相应的开发，目前主要的挑战是怎样在大规模网络服务器的环境下运行并不引入系统regression。

• Soft_limit Reclaim In Over-committed Environment：Over-commitment是普遍采用的提高系统资源利用率的配置。在今年的LSF上我提出利用memcg已有的Soft_limit接口在page reclaim里实现over-commit得到了积极的认可。这次讨论包括RedHat、Google和openSUSE在内的工程师把现有的实现做了进一步改善，之后会有具体细节发布在linux－mm的邮件列表里面。

• Per-memcg Dirty Limit Accounting：Linux支持设置系统允许的dirty page数目的上界，但没有支持针对每个Cgroup的支持。如果只是依靠系统的设置，很容易造成Cgroup被Out-Of-Memory Kill。Google的实现方法得到了大家一致的认可，接下来应该很快被引入upstream里。

这次会后一个很大的感受是越来越多核心内存管理的开发者加入了memcg的讨论和研发。记得2010年10月我去渥太华参加Linux Symposium（OLS)，当时和IBM的Balbir Singh（memcg的作者和维护者）讨论接下来的开发项目和相关细节, 大部分的讨论都是我和他在会后进行的。今年在旧金山的Linux Storage and Filesystem Summit上，很大一部分会上时间就开始讨论memcg相关的开发细节了。所有这些变化很记Linux Kernel Summit 2011大会报道.

大的一个推动力是不断增大的用户需求，Google的云计算平台和OpenVZ的虚拟计算平台都是基于Container的，RedHat和openSUSE近期的distribution都有cgroup的支持。和Mel Gorman会后谈到这个问题，统计过去一段时间内存管理的patch，大部分都是和memcg相关的。同时我们都希望能有更多的工程师，尤其是核心的内存管理和文件系统的开发者加入其中的讨论并给出修改意见。

What to do with Android

今年的话题是怎样提高Code Review的质量。大部分子系统的维护者都谈了自己的想法，问题还是集中在没有足够多的资源和时间对每个patch做细致的Review。

简单介绍一下Linux社区开发的流程：所有的patch都要发布在lkml的邮件列表上。作者的名字需要标注在“Signedoff-by”后，当然一个patch也可能有多个作者，最后一个修改过的“Signed-off-by”出现在最下方。比如所有的内存管理patch都要先进入Andrew的mmotm tree，然后Linus会pull mmotm，所以大部分的patch最后两个“Signed-off-by”是Andrew Morton和Linus Torvalds。一个patch一般都是要经过几轮的code review，最终才有希望被接受。当然也有些patch一开始就被否定掉了，主要原因是要解决的问题没有得到一致的认可。如果被多个人Review过，每个Review的人会在Email里打上“Reviewed-by”（相对仔细看过patch的细节）或是“Acked-by”的标注（大致看过patch的细节）。 之后每个子系统的维护者会根据情况把patch加到各自的tree里，最后由Linus决定把各个子系统merge到Linux的tree里。

其中最关键的一步是把要解决的问题阐述清楚，不要一开始就关注实现细节。建议如果是大的feature proposal，最好先发布一个RFC然后附有patch的prototype。另一点是要把正确的人抄送进来，一般是包括维护者和最近在相关代码中改动很多的开发人员。建议多花一些时间做测试，一定量测试结果会大大增加reviewer的信心。最后也是最关键的一点，是要得到用户的认可和支持。每个feature的开发目的都是要解决一个实际问题，就像Linus在会上对Android的评价：“Code that actually is used that is actually worth something。”

最后给工程师一点建议

贡献patch到开源社区一般需要花几倍于开发patch本身的时间，但受益是长远的。有的patch最终没有被接受，有时只是时间的问题。最难的环节一般在开始，怎样解释清楚要解决的问题。如果问题本身被接受了，接下来的实现方法就容易很多了。最后提一下测试程序，这个十分关键，我们很多时候花太多时间去描述要解决的问题，但一张测试结果图通常胜过千言万语。