一位Linux內核開發者的見聞

        文 / 韓瑩

        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 最終沒有被接受，有時只是時間的問題。最難的環節一般在開始，怎樣解釋清楚要解決的問題。如果問題本身被接受了，接下來的實現方法就容易很多了。最后提一 下測試程序，這個十分關鍵，我們很多時候花太多時間去描述要解決的問題，但一張測試結果圖通常勝過千言萬語。