Linux Kernel峰會（簡稱KS）是Linux最重要的年度大會，受邀的是開源組織各個子系統(tǒng)的維護(hù)者和核心開發(fā)者。今年的峰會安排在10月23-25日。作為Google內(nèi)核開發(fā)組和Linux開源開發(fā)的一員，作者受邀參加了今年的KS大會。文中記錄了一些印象較深的討論。

What’s Next For Control Cgroup

Cgroup是內(nèi)核里用來把用戶進(jìn)程分組的機制。

在此基礎(chǔ)上每個子系統(tǒng)（CPU、Memory、Disk和Networking）有相應(yīng)的機制來監(jiān)控和限制資源利用。用cgroup和resource controller來實現(xiàn)多個任務(wù)的資源共享，同時提供每個任務(wù)運行環(huán)境的隔離，從而保證任務(wù)性能的穩(wěn)定性。由于與現(xiàn)有的Virtual Machine在系統(tǒng)性能上保有優(yōu)勢，包括RedHat、openSUSE、Google、IBM、Oracle和Parallel等在內(nèi)的公司都在一定程度上采用了cgroup。

由于越來越多的用戶需求，今年KS上專門安排了有關(guān)cgroup的討論。James Bottomley首先提出了目前cgroup開發(fā)社區(qū)資源不足的問題，包括開發(fā)人員和維護(hù)者?，F(xiàn)有維護(hù)者由于某些原因即將退出，大家一致認(rèn)為需要馬上找到新的維護(hù)者。Andrew Morton指出很多在內(nèi)存管理社區(qū)的patch都是和cgroup相關(guān)的，現(xiàn)在的問題是沒有專門的cgroup開發(fā)人員參與討論和做Code Review，相應(yīng)的patch進(jìn)度就會被放慢。當(dāng)然，同樣的問題在其他子系統(tǒng)里也會出現(xiàn)。James在會后創(chuàng)建了一個新的郵件列表（cgroups@vger.kernel.org)，除了針對cgroup的討論外，所有子系統(tǒng)的controller的討論也建議抄送到這個列表上。不管cgroup現(xiàn)有的實現(xiàn)是否理想，但用途已經(jīng)越來越廣。包括Andrew和Linus都在會上提到cgroup的發(fā)展是不可逆轉(zhuǎn)的，接下來也希望多一些社區(qū)開發(fā)者加入到其中的討論中。

Memory Controller（memcg） Workshop

Memcg建立在cgroup的基礎(chǔ)上，支持memory isolation機制。這次難得的機會，很多核心開發(fā)人員包括維護(hù)者都來到了布拉格，所以在LinuxCon會議期間我們組織了個專門的Workshop。包括來自Google、RedHat、openSUSE、Fujitsu和OpenVZ的十幾位工程師在一起討論了當(dāng)前的開發(fā)進(jìn)度和之后的開發(fā)計劃。這次的Workshop我們主要針對最近的幾個開發(fā)項目進(jìn)行了討論，這里簡單介紹一下幾個重點項目。

• Kernel Memory Accounting：目前3.1內(nèi)核中memcg只支持user page accounting，但由于用戶進(jìn)程也會申請大量kernel memory，沒有相關(guān)的kernel memory accounting會嚴(yán)重影響程序運行性能的穩(wěn)定性。Google和OpenVZ都在參與相應(yīng)的開發(fā)，目前主要的挑戰(zhàn)是怎樣在大規(guī)模網(wǎng)絡(luò)服務(wù)器的環(huán)境下運行并不引入系統(tǒng)regression。

• Soft_limit Reclaim In Over-committed Environment：Over-commitment是普遍采用的提高系統(tǒng)資源利用率的配置。在今年的LSF上我提出利用memcg已有的Soft_limit接口在page reclaim里實現(xiàn)over-commit得到了積極的認(rèn)可。這次討論包括RedHat、Google和openSUSE在內(nèi)的工程師把現(xiàn)有的實現(xiàn)做了進(jìn)一步改善，之后會有具體細(xì)節(jié)發(fā)布在linux－mm的郵件列表里面。

• Per-memcg Dirty Limit Accounting：Linux支持設(shè)置系統(tǒng)允許的dirty page數(shù)目的上界，但沒有支持針對每個Cgroup的支持。如果只是依靠系統(tǒng)的設(shè)置，很容易造成Cgroup被Out-Of-Memory Kill。Google的實現(xiàn)方法得到了大家一致的認(rèn)可，接下來應(yīng)該很快被引入upstream里。

這次會后一個很大的感受是越來越多核心內(nèi)存管理的開發(fā)者加入了memcg的討論和研發(fā)。記得2010年10月我去渥太華參加Linux Symposium（OLS)，當(dāng)時和IBM的Balbir Singh（memcg的作者和維護(hù)者）討論接下來的開發(fā)項目和相關(guān)細(xì)節(jié), 大部分的討論都是我和他在會后進(jìn)行的。今年在舊金山的Linux Storage and Filesystem Summit上，很大一部分會上時間就開始討論memcg相關(guān)的開發(fā)細(xì)節(jié)了。所有這些變化很記Linux Kernel Summit 2011大會報道.

大的一個推動力是不斷增大的用戶需求，Google的云計算平臺和OpenVZ的虛擬計算平臺都是基于Container的，RedHat和openSUSE近期的distribution都有cgroup的支持。和Mel Gorman會后談到這個問題，統(tǒng)計過去一段時間內(nèi)存管理的patch，大部分都是和memcg相關(guān)的。同時我們都希望能有更多的工程師，尤其是核心的內(nèi)存管理和文件系統(tǒng)的開發(fā)者加入其中的討論并給出修改意見。

What to do with Android

今年的話題是怎樣提高Code Review的質(zhì)量。大部分子系統(tǒng)的維護(hù)者都談了自己的想法，問題還是集中在沒有足夠多的資源和時間對每個patch做細(xì)致的Review。

簡單介紹一下Linux社區(qū)開發(fā)的流程：所有的patch都要發(fā)布在lkml的郵件列表上。作者的名字需要標(biāo)注在“Signedoff-by”后，當(dāng)然一個patch也可能有多個作者，最后一個修改過的“Signed-off-by”出現(xiàn)在最下方。比如所有的內(nèi)存管理patch都要先進(jìn)入Andrew的mmotm tree，然后Linus會pull mmotm，所以大部分的patch最后兩個“Signed-off-by”是Andrew Morton和Linus Torvalds。一個patch一般都是要經(jīng)過幾輪的code review，最終才有希望被接受。當(dāng)然也有些patch一開始就被否定掉了，主要原因是要解決的問題沒有得到一致的認(rèn)可。如果被多個人Review過，每個Review的人會在Email里打上“Reviewed-by”（相對仔細(xì)看過patch的細(xì)節(jié)）或是“Acked-by”的標(biāo)注（大致看過patch的細(xì)節(jié)）。 之后每個子系統(tǒng)的維護(hù)者會根據(jù)情況把patch加到各自的tree里，最后由Linus決定把各個子系統(tǒng)merge到Linux的tree里。

其中最關(guān)鍵的一步是把要解決的問題闡述清楚，不要一開始就關(guān)注實現(xiàn)細(xì)節(jié)。建議如果是大的feature proposal，最好先發(fā)布一個RFC然后附有patch的prototype。另一點是要把正確的人抄送進(jìn)來，一般是包括維護(hù)者和最近在相關(guān)代碼中改動很多的開發(fā)人員。建議多花一些時間做測試，一定量測試結(jié)果會大大增加reviewer的信心。最后也是最關(guān)鍵的一點，是要得到用戶的認(rèn)可和支持。每個feature的開發(fā)目的都是要解決一個實際問題，就像Linus在會上對Android的評價：“Code that actually is used that is actually worth something。”

最后給工程師一點建議

貢獻(xiàn)patch到開源社區(qū)一般需要花幾倍于開發(fā)patch本身的時間，但受益是長遠(yuǎn)的。有的patch最終沒有被接受，有時只是時間的問題。最難的環(huán)節(jié)一般在開始，怎樣解釋清楚要解決的問題。如果問題本身被接受了，接下來的實現(xiàn)方法就容易很多了。最后提一下測試程序，這個十分關(guān)鍵，我們很多時候花太多時間去描述要解決的問題，但一張測試結(jié)果圖通常勝過千言萬語。