一位內核開發者的見聞
http://www.programmer.com.cn/9202/
文 / 韓瑩
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最終沒有被接受，有時只是時間的問題。最難的環節一般在開始，怎樣解釋清楚要解決的問題。如果問題本身被接受了，接下來的實現方法就容易很多了。最後提一下測試程式，這個十分關鍵，我們很多時候花太多時間去描述要解決的問題，但一張測試結果圖通常勝過千言萬語。
本文選自《程式師》雜誌2011年12期
