一位Linux内核开发者的见闻
openkk 13年前
<p> 文 / 韩莹</p> <p> Linux Kernel 峰会（简称 KS）是 Linux 最重要的年度大会，受邀的是开源组织各个子系统的维护者和核心开发者。今年的峰会安排在 10 月 23-25日。作为 Google 内核开发组和 Linux 开源开发的一员，作者受邀参加了今年的 KS 大会。文中记录了一些印象较深的讨论。<strong><a><img style="display:block;margin-left:auto;margin-right:auto;" title="未命名_副本_副本" alt="一位Linux内核开发者的见闻" src="https://simg.open-open.com/show/839de6199afac5f069de2154af19e4dd.jpg" width="600" height="384" /></a></strong></p> <p> <strong>What’s Next For Control Cgroup</strong></p> <p> Cgroup 是内核里用来把用户进程分组的机制。</p> <p> 在此基础上每个子系统（CPU、Memory、Disk 和 Networking）有相应的机制来监控和限制资源利用。用 cgroup 和 resource controller 来实现多个任务的资源共享，同时提供每个任务运行环境的隔离，从而保证任务性能的稳定性。由于与现有的 Virtual Machine 在系统性能上保有优势，包括 RedHat、openSUSE、Google、IBM、Oracle 和 Parallel 等在内的公司都在一定程度上采用了 cgroup。</p> <p> 由于越来越多的用户需求，今年 KS 上专门安排了有关 cgroup 的讨论。James Bottomley 首先提出了目前 cgroup 开发社区资源不足的问题，包括开发人员和维护者。现有维护者由于某些原因即将退出，大家一致认为需要马上找到新的维护者。Andrew Morton 指出很多在内存管理社区的 patch 都是和 cgroup 相关的，现在的问题是没有专门的 cgroup 开发人员参与讨论和做 Code Review，相应的 patch 进度就会被放慢。当然，同样的问题在其他子系统里也会出现。James 在会后创建了一个新的邮件列表（cgroups@vger.kernel.org)，除了针对 cgroup 的讨论外，所有子系统的 controller 的讨论也建议抄送到这个列表上。不管 cgroup 现有的实现是否理想，但用途已经越来越广。包括 Andrew 和 Linus 都在会上提到 cgroup 的发展是不可逆转的，接下来也希望多一些社区开发者加入到其中的讨论中。</p> <p> <strong>Memory Controller（memcg） Workshop</strong></p> <p> Memcg 建立在 cgroup 的基础上，支持 memory isolation 机制。这次难得的机会，很多核心开发人员包括维护者都来到了布拉格，所以在 LinuxCon 会议期间我们组织了个专门的 Workshop。包括来自 Google、RedHat、openSUSE、Fujitsu 和 OpenVZ 的十几位工程师在一起讨论了当前的开发进度和之后的开发计划。这次的 Workshop 我们主要针对最近的几个开发项目进行了讨论，这里简单介绍一下几个重点项目。</p> <ul> <li>Kernel Memory Accounting：目前3.1内核中 memcg 只支持 user page accounting，但由于用户进程也会申请大量 kernel memory，没有相关的 kernel memory accounting 会严重影响程序运行性能的稳定性。Google 和 OpenVZ 都在参与相应的开发，目前主要的挑战是怎样在大规模网络服务器的环境下运行并不引入系统 regression。</li> </ul> <ul> <li>Soft_limit Reclaim In Over-committed Environment：Over-commitment 是普遍采用的提高系统资源利用率的配置。在今年的 LSF 上我提出利用 memcg 已有的 Soft_limit 接口在 page reclaim 里实现 over-commit 得到了积极的认可。这次讨论包括 RedHat、Google 和 openSUSE 在内的工程师把现有的实现做了进一步改善，之后会有具体细节发布在 linux－mm 的邮件列表里面。</li> </ul> <ul> <li>Per-memcg Dirty Limit Accounting：Linux 支持设置系统允许的 dirty page 数目的上界，但没有支持针对每个 Cgroup 的支持。如果只是依靠系统的设置，很容易造成 Cgroup 被 Out-Of-Memory Kill。Google 的实现方法得到了大家一致的认可，接下来应该很快被引入 upstream 里。</li> </ul> <p> 这次会后一个很大的感受是越来越多核心内存管理的开发者加入了 memcg 的讨论和研发。记得 2010 年 10 月我去渥太华参加 Linux Symposium（OLS)，当时和 IBM 的 Balbir Singh（memcg 的作者和维护者）讨论接下来的开发项目和相关细节， 大部分的讨论都是我和他在会后进行的。今年在旧金山的 Linux Storage and Filesystem Summit 上，很大一部分会上时间就开始讨论 memcg 相关的开发细节了。所有这些变化很记 Linux Kernel Summit 2011 大会报道.</p> <p> 大的一个推动力是不断增大的用户需求，Google 的云计算平台和 OpenVZ 的虚拟计算平台都是基于 Container 的，RedHat 和 openSUSE 近期的 distribution 都有 cgroup 的支持。和 Mel Gorman 会后谈到这个问题，统计过去一段时间内存管理的 patch，大部分都是和 memcg 相关的。同时我们都希望能有更多的工程师，尤其是核心的内存管理和文件系统的开发者加入其中的讨论并给出修改意见。</p> <p> <strong>What to do with Android</strong></p> <p> 今年的话题是怎样提高 Code Review 的质量。大部分子系统的维护者都谈了自己的想法，问题还是集中在没有足够多的资源和时间对每个 patch 做细致的 Review。</p> <p> 简单介绍一下 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 里。</p> <p> 其中最关键的一步是把要解决的问题阐述清楚，不要一开始就关注实现细节。建议如果是大的 feature proposal，最好先发布一个 RFC 然后附有 patch 的 prototype。另一点是要把正确的人抄送进来，一般是包括维护者和最近在相关代码中改动很多的开发人员。建议多花一些时间做测试，一定量测试结果会 大大增加 reviewer 的信心。最后也是最关键的一点，是要得到用户的认可和支持。每个 feature 的开发目的都是要解决一个实际问题，就像 Linus 在会上对 Android 的评价：“Code that actually is used that is actually worth something。”</p> <p> <strong>最后给工程师一点建议</strong></p> <p> 贡献 patch 到开源社区一般需要花几倍于开发 patch 本身的时间，但受益是长远的。有的 patch 最终没有被接受，有时只是时间的问题。最难的环节一般在开始，怎样解释清楚要解决的问题。如果问题本身被接受了，接下来的实现方法就容易很多了。最后提一 下测试程序，这个十分关键，我们很多时候花太多时间去描述要解决的问题，但一张测试结果图通常胜过千言万语。</p> <div id="come_from"> 来自: <a id="link_source2" href="/misc/goto?guid=4958202660199755084" target="_blank">www.programmer.com.cn</a> </div> <p></p>