Linux Cgroup v1(中文翻譯)(2)：CPUSETS
英文原文：//www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/cpusets.html
Copyright (C) 2004 BULL SA.
Written by [email protected]
Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
Modified by Paul Jackson <[email protected]>
Modified by Christoph Lameter <[email protected]>
Modified by Paul Menage <[email protected]>
Modified by Hidetoshi Seto <[email protected]>
1 CPUSETS
1.1 CPUSET是什麼？
CPUSETS提供一種機制來給任務分配CPU和內存節點。在本文中「內存節點」指的是包含內存的在線節點（on-line node）。
CPUSETS把任務的cpu和內存限制在當前cpuset內的資源上。他們在虛擬文件系統內組成一個嵌套的層次結構。一些關鍵的鉤子被用來管理任務動態調度。
CPUSETS使用在cgroup文章中描述的通用的cgroup子系統。
根據任務請求，使用sched_setaffinity(2)系統調用中的CPU親和性掩碼來包含CPU，使用mbind(2)和set_mempolicy(2)系統調用中的內存策略來包含內存節點，這些都是是通過任務的cpuset來過濾的，濾除任何不在該cpuset中的CPU和內存節點。調度器不會把任務調度到cpus_allowed向量組（vector）不允許的CPU上，內核頁存分配器（page allocator）不會分配頁面給mems_allowed向量組（vector）不允許的內存節點上。
用戶空間代碼可以根據cgrup虛擬文件系統中的名字來創建和銷毀cpusets，管理它的屬性和權限，以及CPU和內存節點，定義和查詢任務被分配給哪個cpuset，枚舉cpuset中的任務pids。
1.2 為什麼需要cpusets？
大計算機系統的管理，有許多處理器（CPUs）、複雜內存緩存架構，NUMA結構的多內存節點，給進程的高效調度和內存管理帶來了額外的挑戰。
通過讓操作系統自動共享請求的任務之間可用的CPU和內存資源，小型系統能夠高效運行。
但是那些較大的系統，雖然得益於精心配置的處理器和內存調度，可以減少內存訪問次數及訪問競爭，但也意味着客戶會有更大的投入，他也還是可以通過給任務安排合適大小的系統子集來受益。
這些情況下尤其有價值：
- Web服務器運行多個相同的web應用實例，
- 服務器運行不同的應用（例如web服務器和數據庫），或者
- NUMA系統運行要求高性能特性的大HPC應用
這些子集或者說「軟分區」（soft partitions）必須能隨着任務的改變動態調整而不能影響到其他正在並發執行的任務。運行任務的頁存位置也可以隨着內存位置的改變而移動。
內核cpuset補丁提供了實現這個子集的最小化基本內核機制。它權衡了內核中現存的CPU和內存調度功能，避免對關鍵的調度器和內存分配器代碼帶來額外的影響。
1.3 cpusets是如何實現的？
cpusets提供了一種內核機制來限制進程或者進程集合使用的CPU和內存節點。
內核已經有一對機制來定義任務可以被調度到哪個CPU(sched_setaffinity)和獲得內存的哪個節點(mbind, set_mempolicy)。
cpusets是這樣來擴展這兩種機制的：
- cpusets是允許使用的CPU和內存節點的集合。
- 系統中的每個任務被綁定到cpuset，是通過任務結構中的指針指向引用計數的cgroup結構實現的。
- 對sched_setaffinity的調用會選擇任務所在cpuset中允許的CPU。
- 對mbind和set_mempolicy的調用會選擇任務所在cpuset中允許的內存節點。
- 根cpuset（root cpuset）包含所有的系統CPU和內存節點。
- 對任何cpuset來說，可以定義子cpusets，包含了父CPU和內存節點資源的子集合。
- cpusets的層次架構掛載在/dev/cpuset，可以從用戶空間來瀏覽和操作。
- cpuset可以標記為獨佔的，以確保沒有其他的cpuset（除了直系祖宗和後代）會包含重疊的CPU和內存節點。
- 可以枚舉綁定到cpuset上的所有任務（通過pid）
cpusets的實現需要很少的簡單的鉤子來連接到內核，他們都不在性能關鍵路徑上（performance critical paths）：
- 在init/main.c中,系統啟動時初始化根cpuset。
- 在fork和exit時,從cpuset中綁定和解綁任務。
- 在sched_setaffinity中的掩碼來標記cpuset所允許的CPU。
- 在sched.c的migrate_live_tasks()函數中，來保持任務在cpuset允許的CPU之間遷移。
- 在mbind和set_mempolicy的系統調用，用掩碼來標記在cpuset允許的內存節點。
- 在page_alloc.c中，限定內存分配到允許節點。
- 在vmscan.c中限制頁存恢復到當前的cpuset。
你應當掛載cgroup文件類型來使能對cpuset的瀏覽和修改。沒有為cpusets添加新的系統調用，cpusets的所有查詢和修改都是通過cpuset文件系統來支持的。
每個任務的/proc/
Cpus_allowed: ffffffff,ffffffff,ffffffff,ffffffff
Cpus_allowed_list: 0-127
Mems_allowed: ffffffff,ffffffff
Mems_allowed_list: 0-63
每個cpuset是用cgroup文件系統中的目錄表示的，（在標準cgroup文件頂部）包含這些文件：
- cpuset.cpus: cpuset中的CPU列表
- cpuset.mems: cpuset中的內存節點列表
- cpuset.memory_migrate: 是否移動內存頁到cpuset節點？
- cpuset.cpu_exclusive: 是否獨佔CPU？
- cpuset.mem_exclusive: 是否獨佔內存?
- cpuset.mem_hardwall: 內存分配是否hardwalled？
- cpuset.memory_pressure: cpuset中的頁存壓力測量
- cpuset.memory_spread_page標記: 是否使用擴展高速頁存（page cache）
- cpuset.memory_spread_slab標記: 是否使用擴展高速slab(slab cache)
- cpuset.sched_load_balance標記: 是否使用負載均衡
- cpuset.sched_relax_domain_level: 任務遷移時的搜索範圍
此外，根cpuset下還有下列文件：
- cpuset.memory_pressure_enabled：是否計算內存壓力
使用mkdir系統調用或者shell命令來創建新的cpusets。允許使用CPU和內存節點、以及綁定任務等cpuset屬性（例如標記），可以通過寫入上面列舉的cpusets目錄中的對應文件來修改。
嵌套cpuset層次結構允許把大系統分割成嵌套的動態更改的軟分區。
每個任務對cpuset的綁定，在fork時被它的子任務自動繼承，允許系統上的工作負載組織到相關的任務集合，每個集合被限定為使用指定的cpuset中的CPU和內存節點。任務可以被重新綁定到其他的cpuset，只要cpuset文件系統目錄權限允許就行。
這種在大的系統級的管理，和在單個任務和內存區域上使用sched_setaffinity、mbind以及set_mempolicy系統調用所做的細節處理，實現了平滑的集成。
下列規則適用於每個cpuset：
- CPU和內存節點必須是它的父級的子集。
- 除非他的父級是獨佔的，否則不能標記為獨佔。
- 如果cpu或者內存是獨佔的，他們不能跟任何兄弟級別有重疊。
這些規則和cpusets層次的獨佔性，不必每次掃描所有cpuset的改變，就能保證獨佔性的cpuset不會有重疊發生。而且，用linux虛擬文件系統vfs來表示cpuset層次架構，為cpusets提供了權限和命名空間，只用最小的額外的內核代碼改變就有效實現了。
在根cpuset(頂層cpuset)中的cpus和內存文件是只讀的。cpu文件使用cpu熱插拔通知器自動跟蹤cpu_online_mask的值，使用cpuset_track_online_nodes()函數鉤子來自動跟蹤node_states[N_MEMORY]（就是內存節點）的值。
cpuset.effective_cpus和cpuset.effective_mems文件分別是cpuset.cpus和cpuset.mems文件的只讀副本。如果cpuset文件系統以特定的cpuset_v2_mode選項掛載，這些文件的行為將和cpuset v2版本的相關文件類似。換句話說，熱插拔事件不會改變cpuset.cpus和cpuset.mems。這些事件將隻影響到cpuset.effective_cpus和cpuset.effective_mems，他們會顯示cpuset當前真正在使用的cpu和內存節點。更多的cpuset v2版本的行為請參看Control Group v2版本。
1.4 什麼是獨佔cpusets（exclusive cpusets）？
如果一個cpuset是獨佔式cpu或內存，除了直系祖宗和子孫外，其他cpuset不可以共享相同的CPU和內存節點。
有cpuset.mem_exclusive或者cpuset.mem_hardwall屬性的cpuset是「hardwalled」，也就是說，它限制內核分配page，buffer和內核多用戶公共共享的其他數據。所有的cpusets，不管是否是hardwalled，禁止為用戶空間分配內存。當分隔cpuset中的任務進行用戶分配時，可以使能系統的配置，以便幾個互不相關的任務能共享公共的內核數據，例如文件系統頁存。要做到這點，需要構建一個大的內存獨佔的cpuset來持有所有任務，為每個單獨的任務構建非獨佔內存的子cpuset。僅僅少量的內核內存（例如來自中斷處理器的請求），允許從獨佔內存的cpuset之外獲取。
1.5 什麼是內存壓力 （memory_pressure）？
cpusets的內存壓力提供了簡單的cpuset百分比度量方法，任務可以試着釋放cpuset節點中的使用內存來滿足額外的內存需求。
這樣能使得運行在專用cpuset中的任務監測管理員可以有效的探測任務正在產生的內存壓力處理在什麼水平。
這樣是有用的，不管是一個運行大量混合任務的管理系統（其任務可以選擇結束或者重新按重要程度排列，這些任務想要使用比節點允許的更多內存），還是一個緊密耦合的長期運行的大量的並行科學計算任務，如果使用超出允許範圍的更多內存，他們明顯不能滿足性能目標。
這個機制給管理員提供了一種非常經濟的方式來監測cpuset的內存壓力信號。隨後就看管理員或者其他用戶如何來決定採取什麼措施了。
除非這個特性已經通過寫「1」到文件/dev/cpuset/memory_pressure_enabled的方式使能，否則在__alloc_pages()函數代碼中的鉤子就會收到通知.因此只有使能了這個特性的系統可以計算度量。
為什麼按cpuset來平均運行：
- 因為這種測量是按cpuset的，而不是按任務的，受監控測量調度器影響的系統負載在大系統中會明顯減少，因為查詢可以避免批量掃描任務列表。
- 因為這種測量是運行時平均（runing average），而不是累加計數器，調度器能以單次讀取的方式來探測到內存壓力，而不用周期性的讀取和計算結果。
- 因為這種測量是按cpuset而不是按任務，調度器以單次讀取的方式得到cpuset內存壓力，而不用去查詢和計算所有cpuset中的任務集合。
每個cpuset的簡單數字過濾器（需要spinlock和每個cpuset數據的3個詞彙）被保留，如果他進入了同步(直接)頁存回收代碼的話，就由綁定到cpuset的任務來更新。
每個cpuset文件提供了一個整數來表示最近cpuset中的任務造成的直接頁存回收的比率，以每秒千次嘗試回收為單位。
1.6 什麼是內存擴展memory spread？
每個cpuset有兩個布爾值標記文件來控制內核在哪裡為文件系統緩衝和相關的內核數據結構分配頁存，他們就是cpuset.memory_spread_page和cpuset.memory_spread_slab。
如果設置了cpuset.memory_spread_page文件，那麼內核將在所有的允許使用故障處理任務的節點上平均地擴展文件系統緩衝（頁存），而不是把這些頁存放置在該任務運行的節點上。
如果設置了cpuset.memory_spread_slab，那麼內核將為索引節點（inodes）和目錄項（dentries）平均地擴展跟slab緩存相關的文件系統。他將在所有允許使用故障處理任務的節點上擴展文件系統，而不是在該任務正在運行的節點上放置頁存。
這些標記的設置並不會影響到匿名數據段或者任務的堆棧段頁。
默認情況下，兩種內存擴展都是關閉的，除了根據任務的NUMA內存策略或者cpuset配置修改之外，只要有充足的空閑內存頁可用，內存頁就會被分配到運行任務的本地節點上。
當新的cpusets創建，他們會繼承他們父級的內存擴展設置。
設置內存擴展會影響到相關的頁存分配或者slab緩存分配，任務的NUMA內存策略會被忽略。使用mbind()或者set_mempolicy()調用來設置NUMA內存策略的任務，由於他們包含了內存擴展設置，將不會在這些調用中通知任何變化。如果關閉了內存擴展，那麼當前定義的NUMA內存策略就會對內存頁存分配再次適用。
cpuset.memory_spread_page和cpuset.memory_spread_slab都是布爾值標記文件。默認情況下他們包含「0」值，表示特性是關閉的，如果向文件中寫入「1」,就會打開這個命名特性。
實現方式很簡單。
設置cpuset.memory_spread_page將會為該cpuset中或者隨後要加入該cpuset的每個進程打開標記PFA_SPREAD_PAGE。針對頁面緩存的頁存分配函數調用被修改以對PFA_SPREAD_PAGE標記進行內嵌檢查，如果設置該標記，對cpuset_mem_spread_node()的調用會返回將要分配的節點。
同樣地，設置cpuset.memory_spread_slab將會打開進程標記PFA_SPREAD_SLAB。從cpuset_mem_spread_node()返回的頁存節點會被標記為slab緩存。
cpuset_mem_spread_node()程序也很簡單， 它使用每個任務的cpuset_mem_spread_rotor值來選擇當前任務允許內存中的下一個節點作為分配結果。
這種內存調度策略，稱為輪詢調度（round-robin）或者交叉調度（interleave）.
這種策略能為這些任務提供重大的改進，需要放置線程本地數據在相關節點上的任務，需要訪問大文件系統數據集合而他們在任務的cpuset中必須被擴展來跨多個節點的任務。如果沒有這些策略，特別是對可能有一個正在讀取數據集合的線程的任務，跨節點的分配就會變得非常不方便。
1.7 什麼是負載均衡調度sched_load_balance？
內核調度器（kernel/sched/core.c）自動均衡負載任務。如果一個CPU未充分利用，運行在該CPU上的內核代碼將搜尋其他過載CPU上的任務，移動這些任務到自己的CPU上，當然它是在cpusets和sched_setaffinity調度機制的限制之內。
負載均衡的算法成本和它對關鍵共享內核數據結構（例如任務列表）的影響，相比正在做均衡化的CPU數量是線性增加的。因此調度器已經支持把系統CPU分割成很多調度域（sched domain），以便它只需要在每個調度與內做負載均衡。每個調度域覆蓋了系統中的CPU子集；沒有哪兩個調度域是重疊；有些CPU可以不在任何調度域內，因此也不會被負載均衡。
簡而言之，在兩個較小的調度域上做均衡比在一個大的調度域上的成本要少，但是這麼做意味着，在兩個調度域的其中一個過載，將不會均衡到另一個上。
默認情況下，有一個調度域會覆蓋所有CPU，包括那些用內核啟動時間「isolcpus=」參數標記為孤立的(isolated)的CPU。然而，這些孤立的CPU不會參與負載均衡，除非明確指派，不然也不會有任務運行其上。
這個默認的跨所有CPU的負載均衡不是很適合下面兩種情況：
- 在大系統中，負載均衡跨很多CPU是很昂貴的。如果系統是使用cpuset來放置不相關的任務到不同的CPU集合的方式來管理的，完全的負載均衡就是沒有必要的。
- 那些支持某些CPU實時性的系統必須減少在這些CPU上的系統開銷，包括避免任務不必要地負載均衡。
當cpuset標記cpuset.sched_load_balance被使能（默認值），它就請求cpuset.cpus中的包含的所有的CPU包含到單個調度域中，確保負載均衡能從cpuset中的一個CPU移動任務（沒有被sched_setaffinity固定住的）到任意其他的CPU上。
當cpuset的cpuset.sched_load_balance標記被禁用，那麼調度器就會避免在該cpuset上負載均衡，除非是在某些已經使能了sched_load_balance的重疊的cpuset上。
舉個例子，如果頂層cpuset使能了cpuset.sched_load_balance，那麼調度器將有一個調度域覆蓋所有的CPU，在任何其他的cpuset內設置cpuset.sched_load_balance標記將不會有問題，因為我們已經完全地負載均衡了。
因此在上述兩種情況中，頂層cpuset的cpuset.sched_load_balance標記應該禁用，只有那些較小的子cpuset可以使能這個標記。
當這麼做了之後，你通常就不要想在頂層使用了大量CPU的cpuset中放置任何未綁固（unpinned）的任務，因為這些任務，根據其子系(decendant)中設置的特性標記，可能被人為地限定到了某些CPU子集上。縱使這個任務能使用其他某些CPU中的空閑CPU周期，內核調度器也不可能會考慮負載均衡到那些未使用的CPU上。
當然，綁固到特定CPU上的任務可能會被放在禁用了cpuset.sched_load_balance標記的cpuset裏面，然後這些任務就不會再到任何其它的地方了。
這裡在cpusets和調度域之間有一個匹配誤差(impedance mismatch)。cpuset是分層的和嵌套的，調度域是扁平的。他們不會重疊，每個CPU至少在一個調度域中。
對調度域來說，它必須是扁平的，因為跨越了部分重疊CPU集合的負載均衡將帶來超出我們理解的不穩定動態。因此如果兩個部分重疊的cpuset中的每一個都使能了cpuset.sched_load_balance標記，那麼我們就執行單個調度域，它是這兩個cpuset的超集。我們將不會移動任務到cpuset之外的CPU上，但是調度器負載均衡代碼可能浪費了一些計算周期來考慮這個可能性。
這種不匹配就是為什麼在cpuset.sched_load_balance標記被使能的cpuset和調度域配置之間沒有一種簡單的一對一關係。如果cpuset使能了標記，它將得到了跨所有CPU的均衡，但是如果禁用了標記，它將只會確保沒有負載均衡，只要沒有其他重疊的cpuset使能了這個標記。
如果兩個cpuset有部分重疊的cpuset.cpus，只要其中一個使能了這個標記，那麼另一個可能發現他的任務只是在重疊的CPU上被部分地負載均衡了。這只是上面示例圖中頂層cpuset的常見情況。在一般情況下，在頂層cpuset案例中，不會放置可能使用大量CPU的任務在部分負載均衡的cpuset中，他們可能會人為被限定到某些CPU的子集中，不能負載均衡到其他的CPU上。
那些通過「isolcpus=」內核啟動參數設置在cpuset.isolcpus中的CPU會被從負載均衡中排除，永遠不會被負載均衡，不管是否在任何cpuset中設置了cpuset.sched_load_balance值。
1.7.1 sched_load_balance實現細節
每個cpuset的cpuset.sched_load_balance標記默認是使能的（跟大部分的cpuset標記相反），當使能標記之後，內核將確保能夠在cpuset內的所有CPU上負載均衡。（確保所有的在cpus_allowed標記內的所有CPU在同一個調度域內）
如果兩個重疊的cpuset都使能了cpuset.sched_load_balance，那麼他們將都在同一個調度域內。
如果頂層cpuset默認使能了cpuset.sched_load_balance，那麼上面的情況就意味着，不管其他的cpuset設置了什麼，有一個調度域覆蓋了整個系統，
內核保證用戶空間將會避免負載均衡。它將儘可能合適的選擇調度域的分割力度，以便仍舊可以給使能cpuset.sched_load_balance標記的任何CPU集合提供負載均衡。
內部的面向調度器接口的內核cpuset，從cpuset代碼傳遞系統負載均衡的CPU partition（a partition of the load balanced CPUs）到調度器代碼。這個partition是互不相交的CPUs的子集（以cpumask結構數組的形式呈現），它必須要做負載均衡。
cpuset代碼構建了一個新的這樣的partition（翻譯成『分拆集』？），把它傳遞給調度器的調度域構建代碼，以便在下列情況下按需重建調度域：
- cpuset中CPUs不為空，cpuset.sched_load_balance標記發生變化，
- 或者CPUs調進/調出cpuset，而這個cpuset.sched_load_balance標記已經使能了，
- 或者cpuset中CPUs不為空，cpuset.sched_load_balance標記已經使能了，cpuset.sched_relax_domain_level的值發生了變化，
- 或者cpuset中CPUs不為空，而標記已經使能的cpuset被移除了。
- 或者cpu被脫機/聯機（offlined/onlined）
這個partition清楚地定義了調度器應該構建什麼樣的調度域：為partition內的每個單元（cpumask結構）建一個調度域。
調度器會記住當前激活的調度域partitions。當調度器程序partition_sched_domains() 被從cpuset代碼調用來更新這些調度域的時候，它會比較當前的和新請求的partition，然後更新調度域，移除舊的，添加新的。
1.8 什麼是sched_relax_domain_level？
TODO： 以後再翻譯……
1.9 如何使用cpusets？
為了最小化cpuset對關鍵內核代碼（例如調度器）的影響，又由於內核不支持一個任務直接更新另一個任務的內存安置（memory placement），一個任務改變它自己的cpuset上的CPU和內存節點，或者一個任務改綁某個任務到某個cpuset上，這些影響是很小的。
如果修改了cpuset的內存節點，那麼對於綁定其上的任務來說，下次內核就為這些任務分配內存，將會通知任務的cpuset發生了變化，然後更新每個任務的內存布局，從而繼續保持在新的cpuset內存布局內。如果任務正在使用內存策略MPOL_BIND，而已經被綁定的節點跟它的新cpuset有重疊，那麼任務將繼續使用MPOL_BIND節點的子集而不管它們是否仍然在新cpuset中被允許，（有幾句廢話翻譯起來很費勁…）
如果修改了cpuset的cpuset.cpus，cpuset中的任務將立即改變他們的CPU位置(CPU placement).同樣的，如果任務的pid被寫到另一個cpuset的tasks文件，那麼也會立刻改變他的CPU位置。如果任務已經使用sched_setaffinity() 調用來綁定到某個cpuset子集上，該任務允許運行在新cpuset的CPU上。
簡而言之，cpuset被改變，內核就會改變任務的內存位置，該任務的下次頁存分配和處理器位置立刻被更新。
一旦頁存被分配了主內存的物理頁，那麼頁存就可能駐留在已分配的任何節點上，哪怕cpuset內存調度策略cpuset.mems隨後就會改變。如果cpuset.memory_migrate標記設為true，那麼當任務被綁定到cpuset上，該任務在舊cpuset內存節點上分配的頁存都會被遷移到新的cpuset內存節點上。在此遷移操作期間，cpuset中的相對頁存位置會被預留。舉個例子，如果頁存在舊cpuset的第二個有效節點上，那麼頁存可能會被放在新cpuset的第二個有效節點上。
如果cpuset.memory_migrate設為true，然後修改了cpuset.mems，分配在cpuset.mems的舊節點上的頁存將會被移動到新設置的內存節點上。不在該任務舊cpuset上的頁存、或者不在cpuset舊的cpuset.mems設置中的頁存則不會移動。
上述情況有一個例外。如果用來移除所有CPU的熱插拔(hotplug)功能分配給了某個cpuset，該cpuset上的所有任務就會移動到最近的帶有非空CPU的祖先上。但是，如果cpuset跟其他有任務綁定限制的cgourp子系統綁定，一些(或者所有)任務的移動可能會失敗。在綁定失敗的情況下，這些任務仍舊駐留在原來的cpuset上，內核將自動更新他們的cpus_allowed。當移除內存節點的內存插拔功能可用，該異常情況處理也是一樣。一般情況下，內核會違反cpuset調度規則，它會讓有挨餓任務的cpuset中的CPU或者內存節點都脫機離線(offline)。
還有一種例外，GFP_ATOMIC請求是內核必須立即滿足的內部分配。如果GFP_ATOMIC請分配失敗，即使發生panic，內核也會摘除（drop）某個請求。如果請求不能在該任務的cpuset內得到滿足，那麼我們就解開（relex）cpuset，儘可能尋找內存。違反cpuset規則好過給內核增加壓力。
把任務包含到cpuset中的操作步驟：
1. mkdir /sys/fs/cgroup/cpuset
2. mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
3. Create the new cpuset by doing mkdir』s and write』s (or echo』s) in the /sys/fs/cgroup/cpuset virtual file system.
4. Start a task that will be the 「founding father」 of the new job.
5. Attach that task to the new cpuset by writing its pid to the /sys/fs/cgroup/cpuset tasks file for that cpuset.
6. fork, exec or clone the job tasks from this founding father task.
舉個例子，下面的命令序列就是構建名字為Charlie的cpuset，僅僅包含CPU 2和3,內存節點1,在該cpuset中啟動一個子shell ‘sh’:
mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
cd /sys/fs/cgroup/cpuset
mkdir Charlie
cd Charlie
/bin/echo 2-3 > cpuset.cpus
/bin/echo 1 > cpuset.mems
/bin/echo $$ > tasks
sh
# The subshell 'sh' is now running in cpuset Charlie
# The next line should display '/Charlie'
cat /proc/self/cpuset
有幾種方式來查詢或者修改cpusets：
- 直接通過從cpuset文件系統。使用cd、mkdir、echo、cat、rmdir命令或者等效的C語言函數。
- 通過C語言庫libcpuset。
- 通過C語言庫libcgroup。 (//sourceforge.net/projects/libcg/)
- 通過python應用cset。(//code.google.com/p/cpuset/)
sched_setaffinity函數調用也能在Shell提示符中使用，但要通過SGI』s runon或者Robert Love』s taskset。mbind和set_mempolicy函數調用也可以通過shell命令numactl來操作(Andi Kleen』s numa package)。
2 應用實例和語法
2.1 基本用法
創建修改cpuset可以通過cpuset虛擬文件系統來完成。
掛載文件系統：# mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset
在/sys/fs/cgroup/cpuset下你可以看到cpuset樹形結構，/sys/fs/cgroup/cpuset是整個系統的cpuset。
If you want to create a new cpuset under /sys/fs/cgroup/cpuset:
如果想要在/sys/fs/cgroup/cpuset下創建新的cpuset：
# cd /sys/fs/cgroup/cpuset
# mkdir my_cpuset
現在你想要用這個cpuset做點什麼：
# cd my_cpuset
在這個目錄下你能找到幾個文件：
# ls
cgroup.clone_children cpuset.memory_pressure
cgroup.event_control cpuset.memory_spread_page
cgroup.procs cpuset.memory_spread_slab
cpuset.cpu_exclusive cpuset.mems
cpuset.cpus cpuset.sched_load_balance
cpuset.mem_exclusive cpuset.sched_relax_domain_level
cpuset.mem_hardwall notify_on_release
cpuset.memory_migrate tasks
閱讀這些文件，你就會看到cpuset狀態信息：CPU和內存節點，使用它的進程，屬性等。你可以寫這些文件來操作cpuset。
設置標記：
# /bin/echo 1 > cpuset.cpu_exclusive
添加CPU：
# /bin/echo 0-7 > cpuset.cpus
添加內存：
# /bin/echo 0-7 > cpuset.mems
綁定shell到cpuset：
# /bin/echo $$ > tasks
在cpuset內創建cpuset：
# mkdir my_sub_cs
使用rmdir來刪除cpuset：
# rmdir my_sub_cs
如果cpuset正在使用中(內部有cpuset或者已經綁定了進程)，這個操作可能會失敗。
注意：cpuset文件系統是cgroup文件系統中的封裝包。
下面的命令:
mount -t cpuset X /sys/fs/cgroup/cpuset
等同於：
mount -t cgroup -o cpuset,noprefix X /sys/fs/cgroup/cpuset
echo "/sbin/cpuset_release_agent" > /sys/fs/cgroup/cpuset/release_agent
2.2 添加/移除CPU
下列語法用來寫cpuset目錄下的cpu或者內存文件：
# /bin/echo 1-4 > cpuset.cpus -> set cpus list to cpus 1,2,3,4
# /bin/echo 1,2,3,4 > cpuset.cpus -> set cpus list to cpus 1,2,3,4
要添加CPU 6 到cpuset:
# /bin/echo 1-4,6 > cpuset.cpus -> set cpus list to cpus 1,2,3,4,6
要刪除CPU，也是寫入新的列表。
移除所有CPU：
# /bin/echo "" > cpuset.cpus -> clear cpus list
2.3 設置標記
語法很簡單:
# /bin/echo 1 > cpuset.cpu_exclusive -> set flag 'cpuset.cpu_exclusive'
# /bin/echo 0 > cpuset.cpu_exclusive -> unset flag 'cpuset.cpu_exclusive'
2.4 綁定進程
# /bin/echo PID > tasks
注意：這裡是PID，不是PIDs。一次只能綁定一個任務，如果要綁定多個，必須一個接一個的操作：
# /bin/echo PID1 > tasks
# /bin/echo PID2 > tasks
...
# /bin/echo PIDn > tasks
3 問答
Q: 為什麼要使用'/bin/echo'?
A: bash內嵌的echo命令不會檢查對write()調用的錯誤，如果你在控制組文件系統中使用它，你將不知道命令是否執行成功還是失敗。
Q: 當我綁定很多進程時，只有第一行被真正綁定？When I attach processes, only the first of the line gets really attached !
A: 每次對write()的調用只能返回一個錯誤，所以你應該就放一個PID。
