陳鮑孜，吳慶波，譚郁松

（國防科學(xué)技術(shù)大學(xué)計算機學(xué)院，湖南 長沙410073）

1 引言

云計算是繼20世紀(jì)80年代大型機到客戶端－服務(wù)器的大轉(zhuǎn)變后的又一次巨變，它基于互聯(lián)網(wǎng)的計算方式，將共享的軟硬件資源和信息按需提供給計算機和其他設(shè)備。與傳統(tǒng)高性能計算應(yīng)用長時間滿負(fù)荷的系統(tǒng)負(fù)載相比，云計算的系統(tǒng)負(fù)載會隨著事件而波動，服務(wù)器利用率通常在10%～50%。

云計算一方面對服務(wù)資源進(jìn)行聚合并統(tǒng)一調(diào)配，另一方面又對應(yīng)用程序透明并表現(xiàn)出一定程度的虛擬化。進(jìn)行資源聚合的一種重要方式是將不同用戶、不同特征的應(yīng)用聚合起來進(jìn)行混合部署、同時運行。如何更有效地提高云計算中大規(guī)模數(shù)據(jù)中心的服務(wù)器資源利用率，降低基礎(chǔ)架構(gòu)運營開銷，始終是云計算基礎(chǔ)架構(gòu)所重點考慮的問題。

云計算環(huán)境下，應(yīng)用程序混合部署與同時運行要求操作系統(tǒng)能夠有效地進(jìn)行資源管理。有效的資源管理應(yīng)該包括五個方面的內(nèi)容：資源限制、資源隔離、優(yōu)先級、資源統(tǒng)計與資源控制。其中，最關(guān)鍵的因素是資源限制，它包括了以下兩個方面的內(nèi)容：

（1）限制應(yīng)用對資源的消費額度；

（2）當(dāng)資源消費接近額度時，系統(tǒng)采取的相應(yīng)操作。

研究表明，將內(nèi)存回收工作部分提交到應(yīng)用程序的層面來完成會帶來兩大優(yōu)勢：首先，應(yīng)用程序進(jìn)行垃圾回收比系統(tǒng)級的頁面回收所需要的代價相對較??；其次，應(yīng)用程序?qū)λS護緩存頁的冷熱程度更加清楚，回收釋放時更加具有針對性。對于內(nèi)存資源的管理，操作系統(tǒng)與應(yīng)用協(xié)同進(jìn)行管理的模式能夠有效地提升系統(tǒng)的效率。

2 相關(guān)研究

為了降低運營成本，云計算平臺通常需要在保證服務(wù)質(zhì)量QoS（Quality of Service）的前提下盡可能地進(jìn)行資源聚合。常用的資源聚合方式之一是使用虛擬化技術(shù)將不同的服務(wù)整合到同一個物理節(jié)點中，并通過內(nèi)存超售（Overcommit）技術(shù)進(jìn)一步提高物理資源的使用效率。

資源的高度整合使得不同應(yīng)用之間對資源產(chǎn)生競爭。但是，如果采用經(jīng)典操作系統(tǒng)的內(nèi)存管理方式，容易造成不同應(yīng)用之間的性能抖動。為了保證應(yīng)用程序的QoS，人們通常使用系統(tǒng)級虛擬化技術(shù)（如Xen、KVM等）對單獨應(yīng)用程序所消費的內(nèi)存資源進(jìn)行一定程度的隔離，通過氣球驅(qū)動（Balloon Driver）［1］等內(nèi)存管理技術(shù)，使得內(nèi)存資源可以彈性地根據(jù)需求進(jìn)行動態(tài)分配。Schwidefsky M等人［2］在Linux系統(tǒng)上實現(xiàn)了一種協(xié)作式的內(nèi)存管理方法，宿主操作系統(tǒng)與客戶操作系統(tǒng)通過交換共享內(nèi)存頁面的使用與駐留集大小的信息，降低了換頁的概率，提高了系統(tǒng)整體性能。然而，在某些高度聚合云計算應(yīng)用場景中，由于單節(jié)點內(nèi)的應(yīng)用實例不斷增加，系統(tǒng)級虛擬化自身的開銷占總體資源消耗的比重越來越大，因此人們開始尋找更輕量級的解決方案。

同時，為了進(jìn)一步降低應(yīng)用實例之間競爭內(nèi)存資源時帶來的性能抖動，許多研究者提出了操作系統(tǒng)與應(yīng)用程序相互協(xié)同的內(nèi)存管理策略。

Iyer S等人［3］指出，在多數(shù)情況下，操作系統(tǒng)內(nèi)核對應(yīng)用程序?qū)嶋H的內(nèi)存資源使用情況并非十分精確，以至于用戶態(tài)應(yīng)用程序?qū)嶋H上并不總是能夠最優(yōu)化地自動對內(nèi)存進(jìn)行申請與釋放。Yang T等人［4］設(shè)計實現(xiàn)了CRAMM系統(tǒng)，該系統(tǒng)由操作系統(tǒng)內(nèi)核與改進(jìn)后的用戶態(tài)JVM虛擬機兩個重要的部分構(gòu)成。CRAMM的操作系統(tǒng)內(nèi)核負(fù)責(zé)收集、統(tǒng)計系統(tǒng)內(nèi)存資源使用情況并反饋到用戶態(tài)的JVM虛擬機中。用戶態(tài)JVM虛擬機根據(jù)內(nèi)核反饋的信息進(jìn)行有針對性的垃圾回收工作，使得應(yīng)用程序的堆維持在合適大小，提高系統(tǒng)整體吞吐效率。Hines M R等人［5］設(shè)計實現(xiàn)了Ginkgo，將內(nèi)存使用的信息與應(yīng)用程序性能進(jìn)行關(guān)聯(lián)建模，通過在JVM虛擬機實例之間合理地對內(nèi)存資源進(jìn)行重新部署與分配，以較小的性能回退代價節(jié)約了大約27%的內(nèi)存消耗，有效的提升了系統(tǒng)整體聚合能力。

本文在總結(jié)前人研究的基礎(chǔ)之上，結(jié)合Linux內(nèi)核中成熟的進(jìn)程控制組機制以及eventfd事件通知機制，設(shè)計實現(xiàn)了一個簡單高效的應(yīng)用協(xié)同分組內(nèi)存管理的內(nèi)核支撐機制。通過該機制，可進(jìn)一步提升云計算基礎(chǔ)架構(gòu)中內(nèi)存資源利用率。

3 基于進(jìn)程組的內(nèi)存管理

在Linux內(nèi)核發(fā)展的歷史上，人們做了許多關(guān)于進(jìn)程資源分組管理的工作。這些工作可以劃分為兩個方面的內(nèi)容：一類為資源的監(jiān)控，另一類為利用名字空間進(jìn)行隔離。從另一個角度看，這兩方面的工作實際上也是緊密相關(guān)的，它們都試圖防止進(jìn)程不受限制地消耗所有的系統(tǒng)資源，從而獲得更高的系統(tǒng)利用率與更好的QoS。

早期UNIX操作系統(tǒng)關(guān)于資源限制與管理的手段有限，主要是通過XSI擴展中所規(guī)定的getrlimit（）與setrlimit（）系統(tǒng)調(diào)用對內(nèi)核中struct rlimit結(jié)構(gòu)體所描述的資源進(jìn)行的配置。但是，rlimit機制主要是針對單個進(jìn)程的資源，無法對進(jìn)程組進(jìn)行約束。

隨著內(nèi)核級容器虛擬化技術(shù)的出現(xiàn)，人們開始關(guān)注對進(jìn)程組資源進(jìn)行統(tǒng)一管理的機制與策略。在Linux內(nèi)核2.2版本中，由Cox A與Savochkin A共同開發(fā)了User Beancounter機制，用于彌補setlimit（）限制與管理進(jìn)程組的不足。在此基礎(chǔ)上，Emelianov P等人［6］改良了Beancounter的機制，并將其作為Linux內(nèi)核級容器虛擬化Open VZ項目的核心技術(shù)應(yīng)用到實際的工程領(lǐng)域。在Open VZ的實現(xiàn)中，Beancounter代表了進(jìn)程組消費資源的統(tǒng)計，它由一個ID號以及一組資源限制參數(shù)組成。而進(jìn)程分組則依賴于Linux內(nèi)核的名字空間。Open VZ通過將進(jìn)程統(tǒng)一劃分到某個名字空間來實現(xiàn)容器間的隔離，同時完成對容器內(nèi)進(jìn)程集合的內(nèi)存資源限制。

然而，Open VZ作為Linux內(nèi)核級容器虛擬化技術(shù)的代表，更加關(guān)注不同VE（Virtual Environment）之間的隔離性以及對包括vma與kmem在內(nèi)的各種內(nèi)存資源的精確審計。由于不同VE之間需要用名字空間隔離開來，Open VZ中進(jìn)程組實際上以不同的VE為組織單位。而一個VE是一個完整的操作系統(tǒng)用戶空間，包含了必要的運行時環(huán)境及守護進(jìn)程。因此，作為通用的基于進(jìn)程組的內(nèi)存管理技術(shù)，Beancounter顯得不夠靈活。

為了使Linux內(nèi)核具備通用的進(jìn)程組容器機制，Google公司的 Menage P B［7］設(shè)計實現(xiàn)了控制組（Cgroup）。基于Linux內(nèi)核中的控制組機制，人們可以更方便地實現(xiàn)關(guān)于進(jìn)程內(nèi)存資源的分組管理。

3.1 Linux內(nèi)核控制組機制

Linux內(nèi)核控制組的設(shè)計目標(biāo)是為資源管理提供一個統(tǒng)一的框架，包括整合已有的cpuset等子系統(tǒng)，并為未來開發(fā)新的資源管理子系統(tǒng)提供基本的接口。

按照Linux內(nèi)核中的實現(xiàn)，控制組的設(shè)計如圖1所示，包含以下三個重要的概念：

（1）Cgroup，即控制組Control group的簡稱，它是具體控制進(jìn)程行為的分組。Linux內(nèi)核控制組機制中與進(jìn)程分組相關(guān)的資源控制均以其為單位實現(xiàn)。

（2）Hierarchy為一個具有樹狀結(jié)構(gòu)的Cgroup集合，系統(tǒng)中的每一個進(jìn)程都會對應(yīng)到某個Hierarchy中的某個Cgroup。

（3）Subsystem為具體某一類資源控制器的子系統(tǒng)，例如Memory Subsystem為分組內(nèi)存資源管理的一類控制器。其作為Cgroup中可以動態(tài)添加/刪除的模塊，在Cgroup框架下提供多種行為的控制策略。Subsystem必須通過“附屬”（attach）操作關(guān)聯(lián)到具體的Hierarchy上才能產(chǎn)生作用。

這三個概念與各個任務(wù)之間的對應(yīng)關(guān)系如圖2所示，包括以下幾個方面：

（1）每次在系統(tǒng)中創(chuàng)建新的Hierarchy時，該系統(tǒng)中的所有任務(wù)都是其根節(jié)點的初始成員。

Figure 1 Concepts of Cgroup，Hierarchy，Subsystem圖1 Cgroup、Hierarchy、Subsystem概念示意圖

（2）一個Subsystem只能被附屬到一個Hierarchy之上。

（3）一個Hierarchy可以附屬多個Subsystem。

（4）一個任務(wù)可以是多個Cgroup的成員，但必須屬于不同的Hierarchy。

（5）當(dāng)系統(tǒng)中的任務(wù)創(chuàng)建子任務(wù)時，該子任務(wù)將自動成為其父任務(wù)所在的Cgroup成員。系統(tǒng)管理員可以根據(jù)需求將該子任務(wù)遷移到不同的Cgroup中，但在初始創(chuàng)建時它總是繼承其父進(jìn)程所在的控制組。

Figure 2 Relationship of Cgroup components and task圖2 Cgroup各個概念與任務(wù)之間的關(guān)系示意圖

3.2 內(nèi)存控制組

內(nèi)存控制組允許系統(tǒng)以進(jìn)程組為粒度限制管理用戶態(tài)應(yīng)用程序內(nèi)存的消費。相比Beancounter機制，內(nèi)存控制組主要關(guān)心用戶空間頁面。對于隔離性要求不高的應(yīng)用場景，內(nèi)存控制組能夠提供更好的靈活性和相對較低的開銷。

對于每一個內(nèi)存控制組，系統(tǒng)允許管理員設(shè)置該組進(jìn)程的內(nèi)存使用硬上限、軟上限、swappiness等參數(shù)，并提供組內(nèi)OOM（Out of Memory）等行為控制。Linux內(nèi)核在原有基礎(chǔ)上的重新設(shè)計與實現(xiàn)，以更好地完成內(nèi)存控制組所帶來的新機制。下文將從內(nèi)核的設(shè)計與實現(xiàn)兩個角度分別闡述新機制帶來的挑戰(zhàn)。

在設(shè)計層面，主要面臨的是如何處理共享頁面和線程組共享地址空間的問題。為了簡化邏輯，減少統(tǒng)計計數(shù)給系統(tǒng)所帶來的性能回退，內(nèi)存控制組在實現(xiàn)時將多個進(jìn)程組共享的頁面計數(shù)歸屬到第一個訪問該頁面的進(jìn)程組中。同時，為了兼顧公平性，當(dāng)持有共享頁面的進(jìn)程組釋放該頁面時，該頁面的計數(shù)將遷移到其他某個持有該頁面的進(jìn)程組中。由于Linux內(nèi)核中線程是作為一種輕量級的進(jìn)程來處理，因此實際上會存在屬于同一進(jìn)程的不同線程處于不同的Cgroup分組當(dāng)中。而這些線程實際上是共享了相同的地址空間，因此其中相關(guān)的所有頁面的計數(shù)在嚴(yán)格意義上應(yīng)該被不同的分組所共享。但是，內(nèi)核為了簡化實現(xiàn)邏輯，將內(nèi)存的使用計數(shù)僅歸屬于線程組主線程所在的Cgroup分組中。

在實現(xiàn)層面的主要問題是如何高效處理任務(wù)在分組間遷移時的相關(guān)頁面統(tǒng)計計數(shù)。為了提高系統(tǒng)的性能，內(nèi)核在處理相關(guān)邏輯時進(jìn)行了簡化。當(dāng)任務(wù)進(jìn)行遷移時，內(nèi)核僅將任務(wù)本身遷移到新分組當(dāng)中，而之前的統(tǒng)計計數(shù)仍保留在舊分組。當(dāng)原先計數(shù)所代表的內(nèi)存頁面被釋放時，內(nèi)核再在原分組內(nèi)減去對應(yīng)的計數(shù)。在遷移之后產(chǎn)生的新計數(shù)，內(nèi)核會自動統(tǒng)計到新的分組記錄中。

同時，為了盡量減少對內(nèi)核數(shù)據(jù)結(jié)構(gòu)struct page的改動并最大程度地降低開銷，內(nèi)存控制組在實現(xiàn)時將原先全局LRU鏈表劃分為每進(jìn)程組的LRU鏈表，各個組之間的LRU鏈表通過所在Hierarchy的樹狀結(jié)構(gòu)關(guān)聯(lián)起來。因此，當(dāng)內(nèi)核進(jìn)行全局內(nèi)存回收時，將從單一遍歷全局LRU鏈表轉(zhuǎn)變?yōu)閺腃group根節(jié)點開始遍歷各組局部LRU鏈表，進(jìn)行頁面交換與頁面回收。這種設(shè)計雖然帶來了一部分額外的開銷，但簡化了對原有頁面回收實現(xiàn)的修改。

3.3 內(nèi)存控制組與Beancounter對比測試

為了能夠更直觀地了解內(nèi)存控制組在實際應(yīng)用中的性能，本文將其與Beancounter機制進(jìn)行了對比測試。由于Beancounter是Open VZ的核心組成機制之一，因此需要通過Open VZ的虛擬機性能反映。為此，本文選取了LXC（Linux Container）內(nèi)核級虛擬化項目作為內(nèi)存控制組的參照環(huán)境。這兩個項目均基于Linux內(nèi)核，采用相同名字空間機制隔離不同的VE；并且，LXC與Open VZ可以使用相同的用戶態(tài)環(huán)境（即VE的根文件系統(tǒng)）。不同之處在于，LXC項目使用控制組機制進(jìn)行資源限制，而Open VZ使用Beancounter機制。

對比測試的實驗平臺為Intel雙路Xeon E5620（16核）、24 GB（6×4 GB）內(nèi)存，采用麒麟Linux 3.2服務(wù)器操作系統(tǒng)（內(nèi)核版本2.6.32），使用Open VZ官方提供的VE根文件系統(tǒng)，共16個VE，每個VE分配1.5 GB物理內(nèi)存配額，測試用例為Unixbench，結(jié)果如圖3所示。

Figure 3 Performance comparison of open VZ and LXC圖3 Open VZ與LXC性能對比測試結(jié)果

從Unixbench的結(jié)果觀察，使用內(nèi)存控制組的LXC平均性能要高于使用Beancounter的Open VZ，但其VE間性能波動相對較大，隔離性相比較而言不如Open VZ。當(dāng)以提升系統(tǒng)整體吞吐量為主要目標(biāo)時，內(nèi)存控制組相對而言更加合適。

4 應(yīng)用協(xié)同的內(nèi)存管理支撐機制

用程序混合部署與同時運行要求系統(tǒng)軟件能夠有效地進(jìn)行資源管理。目前，Linux內(nèi)核使用內(nèi)存控制組時，主要是通過限制組內(nèi)內(nèi)存分配的硬上限（Limits）與軟上限（Soft Limit）來進(jìn)行管理。當(dāng)組內(nèi)內(nèi)存申請失敗時，在組內(nèi)私有的LRU鏈表上觸動組內(nèi)回收，如果回收失敗，將會觸發(fā)組內(nèi)OOM。當(dāng)應(yīng)用程序充分競爭造成全局內(nèi)存緊張時，系統(tǒng)首先試圖將各組使用內(nèi)存量回收到軟上限，然后再由kswapd內(nèi)核守護線程進(jìn)行全局頁面回收。

研究表明，使用用戶態(tài)協(xié)同的內(nèi)存垃圾回收機制，能進(jìn)一步提升系統(tǒng)整體性能。其主要原因有兩個方面：首先，系統(tǒng)換頁的代價少則只需要進(jìn)行一次IO，多則需要進(jìn)行兩次，而應(yīng)用程序進(jìn)行垃圾回收的代價通常更??；其次，軟上限應(yīng)該設(shè)定的值在實際應(yīng)用中沒有客觀計算標(biāo)準(zhǔn)，而應(yīng)用程序?qū)λS護的緩存頁的冷熱程度更加清楚，回收釋放時更加具有針對性，降低了抖動發(fā)生的概率。

4.1 Linux內(nèi)核eventfd通知機制

可應(yīng)用于傳統(tǒng)UNIX進(jìn)程間的通信機制包括管道、套接字、信號等等。一般情況下，管道機制常被編程者作為通知機制來異步喚醒select（或等價的poll/epoll）調(diào)用。

eventfd是Linux內(nèi)核中一個新的高效線程間事件通知機制，一方面它比傳統(tǒng)的管道少用一個文件描述符；另一方面，eventfd的緩沖區(qū)管理相對簡單，全部緩沖僅有8字節(jié)。利用該通知機制，編程者只需要通過eventfd系統(tǒng)調(diào)用獲得關(guān)于事件的文件描述符，然后使用經(jīng)典的IO函數(shù)監(jiān)聽從該文件描述符傳遞過來的通知事件。

4.2 進(jìn)程組內(nèi)存臨界通知機制的設(shè)計與實現(xiàn)

實現(xiàn)應(yīng)用感知的內(nèi)存管理，在操作系統(tǒng)內(nèi)核一級關(guān)鍵是需要具備兩方面的能力。一方面，資源聚合要求在單一節(jié)點上聚合多個應(yīng)用實例，并且內(nèi)核能為應(yīng)用實例之間提供一定程度的資源隔離與QoS。通過內(nèi)存控制組的支持，資源隔離與QoS能夠在一定程度上得到保障。另一方面，為了能夠進(jìn)一步高效利用系統(tǒng)資源環(huán)境，需要操作系統(tǒng)具備將進(jìn)程組內(nèi)存壓力通知相關(guān)用戶態(tài)應(yīng)用的能力。同時，系統(tǒng)應(yīng)該提供靈活的機制供應(yīng)用程序?qū)?nèi)存資源的具體需求反饋給操作系統(tǒng)，以便系統(tǒng)能夠做出更精確的資源控制。

為了達(dá)到以上目標(biāo)，本文完成了以下兩個方面的工作。首先，將eventfd的機制與Linux內(nèi)核控制組相結(jié)合，通過向Cgroup虛擬文件系統(tǒng)中指定的控制文件進(jìn)行配置將兩種機制關(guān)聯(lián)起來，實現(xiàn)針對各個控制組的事件通知機制的框架。然后，在前者的基礎(chǔ)上，為每個內(nèi)存控制組增加內(nèi)存使用閾值數(shù)組。分組內(nèi)的應(yīng)用根據(jù)自身的特點將預(yù)期的閾值通過Cgroup文件系統(tǒng)寫到該數(shù)組中。當(dāng)進(jìn)程組所消耗的內(nèi)存數(shù)量超過閾值時，內(nèi)核將通過eventfd機制通知相關(guān)應(yīng)用進(jìn)行用戶態(tài)的內(nèi)存垃圾回收。詳細(xì)設(shè)計的示意圖如圖4所示。

Figure 4 Processes group notification mechanism圖4 進(jìn)程組通知機制示意圖

通過Cgroup虛擬文件系統(tǒng)進(jìn)行關(guān)聯(lián)，避免了增加新的系統(tǒng)調(diào)用所帶來的復(fù)雜度。應(yīng)用程序利用傳統(tǒng)的編程接口申請創(chuàng)建并獲得eventfd，并將該eventfd描述符、對應(yīng)的Cgroup控制文件（即cgroup＿subsys＿state在Cgroup虛擬文件系統(tǒng)中關(guān)聯(lián)的文件描述符）以及語義相關(guān)的參數(shù)同時寫入指定的Cgroup控制文件中。內(nèi)核處理該文件的寫入操作時，啟動其對應(yīng)的Cgroup中相關(guān)事件監(jiān)聽與處理邏輯，完成Cgroup與eventfd的關(guān)聯(lián)。

內(nèi)存控制組在分組進(jìn)行charge/uncharge、組內(nèi)頁面進(jìn)行遷移時進(jìn)行閾值檢測，如果超過閾值則通過先前注冊的eventfd向應(yīng)用程序發(fā)送通知。應(yīng)用程序在接到通知后即可進(jìn)行相應(yīng)的處理邏輯。在一個內(nèi)存控制組中，本文設(shè)置了多個閾值的槽位。應(yīng)用程序可以根據(jù)需要在同一個控制組中對多個閾值進(jìn)行監(jiān)聽。為了能夠進(jìn)一步加快處理速度，在向控制組注冊通知的時候，內(nèi)核對存儲閾值的數(shù)組進(jìn)行重新排序，并設(shè)置當(dāng)前閾值指針為不大于當(dāng)前內(nèi)存使用量的最大槽位。

這種設(shè)計盡可能地利用了Linux的已有成熟機制，降低了引進(jìn)新機制后對系統(tǒng)穩(wěn)定性帶來的風(fēng)險，實現(xiàn)了一種簡單可靠的內(nèi)存組臨界通知機制。

4.3 測試與評估

本文的主要工作基于麒麟Linux 3.2服務(wù)器操作系統(tǒng)穩(wěn)定版的2.6.32內(nèi)核，主要目標(biāo)是對新機制所帶來的潛在性能回退進(jìn)行評估。評估的實驗平臺為開啟Virtio機制的KVM虛擬化客戶端操作系統(tǒng)，虛擬機配置為六個CPU核心，2 GB物理內(nèi)存。實驗結(jié)果如圖5和圖6所示。

Figure 5 Comparison of latency圖5 延遲對比

Figure 6 Memory access bandwidth comparison of mmap圖6 mmap訪存帶寬對比

實驗結(jié)果表明，以Cgroup與eventfd為基礎(chǔ)的進(jìn)程組內(nèi)存臨界通知機制是資源聚合環(huán)境下一種簡單實用的內(nèi)存管理方法，且新機制的引入未對現(xiàn)有的穩(wěn)定版內(nèi)核帶來明顯的性能回退。

5 結(jié)束語

在大規(guī)模云計算的環(huán)境下，如何提高系統(tǒng)資源利用率是學(xué)術(shù)界與工業(yè)界一直關(guān)注的重點。本文在前人的研究基礎(chǔ)上，設(shè)計了一種可以由應(yīng)用程序主動向內(nèi)核注冊觸發(fā)內(nèi)存回收條件的機制，兼顧了應(yīng)用對自身內(nèi)存資源了解與系統(tǒng)對全局內(nèi)存資源規(guī)劃兩方面的優(yōu)勢。通過該機制，系統(tǒng)管理員能很容易地完成進(jìn)程組范圍內(nèi)存資源限制，并可以通過eventfd事件通知相關(guān)應(yīng)用在用戶態(tài)進(jìn)行垃圾回收。

下一步的工作，將在這個機制的基礎(chǔ)上實現(xiàn)用戶態(tài)應(yīng)用自主事件的注冊，以及根據(jù)內(nèi)核通知進(jìn)行自主垃圾回收。

［1］ Waldspurger C A.Memory resource management in VMware ESX server［C］∥Proc of the 5th Symposium on Operating Systems Design and Implementation，2002：181－194.

［2］ Schwidefsky M，F(xiàn)ranke H，Mansell R，et al.Collaborative memory management in hosted Linux environments［C］∥Proce of Ottawa Linux Symposium，2007：313－328.

［3］ Iyer S，Navarro J，Druschel P.Application－assisted physical memory management for general－purpose operating systems［R］.Huston，TX 77005，USA：Rice University，2004.

［4］ Yang T，Berger E D，Kaplan S F，et al.CRAMM：Virtual memory support for garbage－collected applications［C］∥Proc of the 7th USENIX Symposium on Operating Systems Design and Implementation，2006：103－116.

［5］ Hines M R，Gordon A，Silva M，et al.Application know best：Performance－driven memory overcommit with ginkgo［C］∥Proc of the 3rd International Conference on Cloud Computing Technology and Science，2011：1.

［6］ Emelianov P，Lunev D，Korotaev K.Resource management：Beancounters［C］∥Proc of Ottawa Linux Symposium，2007：285－292.

［7］ Menage P B.Adding generic process containers to the Linux kernel［C］∥Proc of Ottawa Linux Symposium，2007：46－57.