REEact: 在 多核平臺上的自定義虛擬 執行管理 器

1. REEact: 在多核平臺上的自定義虛擬執行管理器 林鼎原 Dept. of Electrical Engineering National Cheng Kung University Tainan, Taiwan, R.O.C

2. 摘要(1/2) • 當轉移到多核心晶片多處理器（CMPs）時，一個關鍵議題便是如何有效地協調和管理硬體資源和應用程式的執行，以克服在新的計算環境中，來自硬體和應用程式變化之效能、功耗和可靠性等的挑戰。 • 設計一個可以動態適應執行環境的演算法去管理資源和應用程式是困難的。 • 因為大多數的資源和應用程式的管理與監測設施只存在作用於作業系統(OS)層級。 • 本文介紹了REEact，一個提供用戶級別動態適應管理策略能力的基礎架構。 • REEact是一個提供框架(framework)和核心服務(coreservices)的虛擬執行環境，能快速設計自定義之管理策略，做動態管理資源和應用程式的設計。

3. 摘要(2/2) • 為了證明REEact的功能性和實用性，本文主要介紹三個使用REEact案例研究─每一個案例都說明REEact在實際的CMP上運行特定動態管理策略。 • 第一個情況研究探討REEact如何在機器故障的情況下執行自定義的熱管理策略。 • 第二個情況研究說明REEact在一個特定應用策略情況下，其目的是讓使用率達到最高，但同時避免不公平地凍結其它程式的執行。 • 最後一個案例描述使用REEact 去控制硬體預取器(prefetcher)，在不犧牲效能的情況下降低功耗。 • 透過這些案例研究，我們證明REEact能有效地執行策略而實現動態地管理資源和適應搭配各應用程式之執行。

4. 介紹(1/2) • 目前，大多數資源管理策略實現於OS內核(kernel)中。然而，OS並不適合去執行或整合使用者自定義之策略，其原因有兩個: • 1.當OS做管理的決策時，其設計並沒有考量特定應用的資訊。 • 當前的OS不可能做到特定應用資訊的用戶級管理策略去調整應用程式執行的方式。 • 2.增加或調變OS策略的複雜度是很高的。 • 如果沒經過謹慎設計和測試，自定義的策略可能會帶來安全性問題。

5. 介紹(2/2) • 在本文中，我們主張使用一個用戶級的虛擬執行環境 （VEE），提供一個架構易於自定義CMP資源管理策略的整合 和發展。 • 要設計一個用戶級的VEE架構，有一些挑戰需要克服。 • 1.需提供必要的資源管理功能，以方便自定義資源管理策略的發展。 • 這些設備包括分配硬體資源，調整應用程式執行，並在執行時獲取資源和應用程式狀態的資訊。 • 2. VEE實施的策略應根據實際運行時間環境做動態地調整。 • 3. VEE應謹慎設計，使管理開銷不超過自定義管理策略所帶來的利益

6. REEact軟體架構概觀(1/3) • 圖1 概略描述使用REEact執行特定策略的流程圖。 • 圖1. 一個自定義策略需要使用REEact API 來執行兩個程式(procedure)， • 並加入REEact的初始化呼叫到該應用程式。

7. REEact軟體架構概觀(2/3) • 在REEact中，一個特定的策略需要使用REEact所提供的API來實現兩個程式(procedure)： • 一個全域的程式(global procedure) 管理多個應用程式的執行。 • 一個局部的程式( local procedure)管理單一應用程式的執行(和它的執行緒）。 • 為了說明REEact的結構和操作，我們首先提出一個簡單的例子。 • 這個例子中，REEact在16核的CMP上管理了三個多執行緒應用程式的執行。 • REEact管理計算資源的使用（如:核cores）且在執行緒的創建和終止時動態分配或釋放它們，並依循先到先服務（FCFS）的特定策略。 • 三個應用程式App1、App2和APP3，分別創建五、六、七個執行緒。我們假設在執行App2之前App1獲得全部的資源，且在APP3開始執行之前App2獲得所有資源。

8. REEact軟體架構概觀(3/3) • 五個核（C0~C4）被分配給APP1，每一個核對應一個執行緒 • App2產生六個執行緒分配到六個核（C5~C10）。 • 然後APP3開始執行，並要求核（現在剩餘五個未分配的核） • 前五個執行緒每一個執行緒對應一個核。 • 隨著第六個執行緒創建，GEM通知APP3的LEM沒有核可用了。 • LEM則必須映射這個執行緒在已經分配過的核上。 (a) 單一,多執行緒應用程式的REEact管理 (b) 三個,多執行緒應用程式的REEact管理 圖2. REEact使用自定義FCFS策略動態地分配/釋放資源(如:cores)

9. REEact元件(1/4) • REEact提供了架構和服務去做管理策略的執行。 • 透過不同的REEact元件提供如GEM/ LEM溝通和執行緒映射等服務。 • 圖3表示了REEact的基本元件。 • 因為適當的資源管理決策取決於實際應用程式和硬體資源的狀態 • REEact有收集運行時狀態的監控器(monitors)。 • 提供硬體和軟體執行器​​(actuators)去調整資源分配和應用程式執行。 • GEM根據LEM蒐集的運行資訊去做全域性管理決策，溝通元件提供了GEM與LEM的溝通能力。 • REEact還提供了應用程式狀態表，這樣GEM/ LEM可以隨時掌握資源分配。

10. REEact元件(2/4) 圖3. REEact的基本元件

11. REEact元件(3/4) 以下簡要介紹REEact各個元件: • 全域/局部執行管理器（GEM / LEMS）: • A GEM/LEM 被實現作為一輔助執行緒 (a helper thread), • 在應用程式一開始執行時，由REEact 初始化 過程所建立的 • 溝通器在GEM和LEM之間做非同步的資料傳輸。 • 它被設計為一個連接到GEM/ LEM的訊息佇列。 • 每個訊息由三個部分組成：發送者ID，訊息類型和訊息內容。 • 監測器提供了監視硬體和應用程式狀態的功能，它收集了硬體、系統使用率和執行緒狀態的資訊。 • 可收集的硬體資訊，包括效能監測單元（PMU）的輸出，核頻率，核溫度，以及是否啟用特定的硬體元件（例如，預取器，L2 cache等）。 • 系統使用資訊包括每個核心的負載（使用率），和整體的負載。 • REEact也監視應用執行緒的狀態，如執行緒的創建、終止和暫停等狀態。

12. REEact元件(4/4) • 軟體執行器(SWactuator)配置應用程式的執行。 • SW執行器將應用程式和執行緒對應到核上。 • 如何分配核心取決於所使用的策略。 • 硬體執行器(HWactuator)配置一個硬體（HW）元件。 • 一個HW執行器可以決定在核上的硬體（例如，預取器）是否使用，或透過設定 特定模組暫存器（MSR）的特殊(專用?)位元來 調整處理器的頻率。 • 應用程式狀態表（AST）包含目前硬體資源和應用程式的狀態。 • 每個GEM和LEM都有自己的AST，其中包含其控制資源和執行緒訊息。 • AST可以擴展去包括策略所需的資訊。

13. REEact API 表1. 由當前REEact提供的API元件和其相關方法

14. 研究案例 • 為了證明REEact的功能性和實用性，本文主要介紹三個使用REEact案例研究，每一個案例都說明REEact在實際的CMP上運行特定動態管理策略。 • 這些策略解決不同問題: • 1.熱的管理。 • 2.平行程式間的公平性。 • 3.效能/能源消耗 的管理。

15. 案例一:Fighting the Broken Screw(1/6) • 在第一個研究案例中，我們示範如何使用REEact去執行一個策略，並在熱緊急情況下做出反應。 • 如果有任何核的溫度超過出廠預先定義的臨界(門檻)溫度thresholdT1，核的頻率和/或電壓 就會被降低。 • 如果核的溫度持續攀升並達到臨界溫度criticaltemperature T2，核便會暫時關閉。 • 雖然這些機制可以防止災難性的過熱，但對整體系統效能有負面的影響。 • 如果我們能偵測 容易過熱的核，並透過排程減少它使用的頻率，那我們就可以達到更好的效能以及防止不必要的核心過熱。

16. 案例一:Fighting the Broken Screw(2/6) • REEact監控方法支援核心溫度的讀取以及動態的臨界溫度偵測 threshold temperatures T1 and T2。 • APIMethods (page12.) • getCoreTemperature • getTemperatureThreshold1 • getTemperatureThreshold2 • 為了解決broken-screw 熱問題，我們使用REEact發展一套自定義的策略。 • Policy1.a和Policy1.b分別為全域(GEM)和局部(LEM)程式的pseudocode. • 此策略中，GEM和LEM一起偵測過熱並將應用程式執行緒給予適當的搬移。

17. 案例一:Fighting the Broken Screw(3/6) • 執行期間，LEM週期性的(每10秒)檢查是否有任一的核(cores)有過熱。 • 如果過熱的核(core)之溫度介於T1和T2間，LEM便會向GEM請求一個溫度低於T1的核core(Policy 1.b line 16)。 • 如果GEM找到這樣的核(Policy 1.a lines 11-19),變以此新核作為回應 (Policy 1.a lines 35- 37) LEM將執行緒映射到新核上執行(Policy 1.b line 21). • 如果過熱核(core)之溫度大於或等於T2，LEM將此核標註為hot core，並向GEM請求溫度最涼且未被標註的核(Policy 1.b line 13-14). • 一旦GEM找到新核並回應LEM(Policy 1.a lines 21-31),LEM重新將執行緒映射到新核上執行(Policy 1.b line 21). • 若GEM沒找到新核，則維持在 hot core 執行 。

18. 案例一:Fighting the Broken Screw(4/6) Policy1.a Fighting the broken screw: GEMpolicy procedure 1: /* input parameters: ref to all LEM objs, ref to GEM obj, ref to monitor and ref toGEM’s app state table */ 2: INPUT: List lemList, Gem gem, Monitor m, AppStatTbl ast 3: List freeCores←ast.getUnallocCores(); 4: Int T1←m.getTempThreshold1(); 5: Int T2←m.getTempThreshold2(); 6: LOOP 7: Message msg←gem.getMessage(); 8: Lem lem←msg.sender; 9: Core oldCore←msg.value; 10: Core newCore←oldCore; 11: IF msg.type = TemperatureAboveT1 THEN 12: /* 尋找溫度低於T1的core*/ 13: FOR ALL c IN freeCores DO 14: Int t←m.getCoreTemperature(c); 15: IF t < T1 THEN 16: newCore←c; 17: BREAK; 18: END IF 19: END FOR 20: ELSE IF msg.type = TemperatureAboveT2 THEN 21: Int lowestT←T2; 22: /* List of cores that “lem” has used and had thermal issue (core temperature above T2) */ 23: List hotCores←lem.ast.getCoresAboveT2(); 24: /* search for an unallocated core that has lowest temperature and no thermal issue for “lem” yet */ 25: FOR ALL c IN freeCores DO 26: t←m.getCoreTemperature(c); 27: IF hotCores.doNotHave(c) AND (t < lowestT) THEN 28: newCore←c; 29: lowestT←t; 30: END IF 31: END FOR 32: END IF 33: /* ask LEM “lem” to run on newCore */ 34: IF newCore ≠ oldCore THEN 35: lem.sendMessage(runOnCore, newCore); 36: freeCores.add(oldCore); 37: freeCores.remove(newCore); 38: END IF 39: END LOOP

19. 案例一:Fighting the Broken Screw(5/6) Policy 1.b Fighting the broken screw: LEMpolicy procedure 1: /* input parameters: ref to this LEM obj, ref to GEM obj, ref to monitor and ref tothis LEM’s app state table */ 2: INPUT: Lem lem, Gem gem, Monitor m, AppStatTbl ast 3: Int T1←m.getTempThreshold1(); 4: Int T2←m.getTempThreshold2(); 5: /* extend ast with a new list for the cores on which this LEM has thermal issue(core temperature above T2) */ 6: List ast.CoresAboveT2←new List(); 7: LOOP 8: /* single-threaded app has only one thread and one core*/ 9: Core curCore←ast.getCurrentlyUsingCores(); 10:Thread appThread←ast.getAppThreads(); 11: Int coreT←m.getCoreTemperature(curCore); 12: IF coreT ≥ T2 THEN 13: ast.CoresAboveT2.add(curCore); 14: gem.sendMessage(TemperatureAboveT2, curCore); 15:ELSE IF coreT ≥ T1 THEN 16: gem.sendMessage(TemperatureAboveT1, curCore); 17: END IF 18: /* Get message with timeout “timeout” (non-blocking)*/ 19: Message msg←LEM.timeoutGetMessage(timeout); 20: IF (msg ≠ NULL) AND (msg.type = runOnCore) THEN 21: lem.pinThreadstoCores(appThread, msg.value); 22: sleep(timeout); 23: END IF 24: END LOOP

20. 案例一:Fighting the Broken Screw(6/6) • 圖四，利用SPEC2006 benchmarks評估此過熱預防策略，optimal為手動調整後最佳的執行結果，和Linux default scheduler做效能(執行時間)改善的比較， Max speedup16%, average speed up 9.5% 圖4.效能的增進

21. 案例二: 無代價情況下的最大限度使用率(1/3) • 第二個範例中，示範一個REEact策略，其目的是讓使用率達到最高，但同時避免不公平地凍結(starving)其它程式的執行。 • 我們研究一個策略稱作AutoMax，動態地擴展和縮小在REEact內正在執行的程式。 • Policy2.a和Policy2.b分別為全域(GEM)和局部(LEM)程式的pseudocode. • GEM 決定系統必須達到的最大與最小使用率(lines 4-5) • 根據系統附載，GEM詢問應用程式要增加或是減少其執行緒，如果使用率小於最小臨界(min threshod)(line10),LEM 隨機地選擇擴展，同樣地，如果使用率在最大臨界之上， LEM 隨機地選擇縮小。 • LEM擴展或縮小的回應動作是應用程式特定的

22. 案例二: 無代價情況下的最大限度使用率(2/3) Policy 2.aAutoMax: GEM Policy Procedure 1: /* input parameters: ref to LEM objs, ref to GEM obj, ref tomonitor, ref to appstate table */ 2: INPUT: List lemList, Gem gem, Monitor m, AppStatTbl ast 3: 4:Double minUtilization←ast.getTotalCoreCount() - ε1 5: Double maxUtilization←ast.getTotalCoreCount() + ε2 6: LOOP 7: Double curUtilization←m.getSystemLoad() 8:List permutedLL←permute(lemList) 9: /* Depending on system load, ask apps to expand or shrinktheir threads */ 10:IF curUtilization < minUtilization THEN 11: MSGTYPE msgType = expand 12:ELSE IF curUtilization > maxUtilization THEN 13: MSGTYPE msgType = shrink 14: ELSE 15: permutedLL.removeAll() /* No app must change */ 16: END IF 17:/* loop until an app has expanded or shrunk, or until no app can be changed */ 18:Bool didExpandOrShrink←FALSE 19: REPEAT 20: Lem lem←permutedLL.getFirst&Remove() 21:lem.sendMessage(msgType, NULL) 22: Message msg←gem.getMessage() 23: IF msg.type = changeResponse AND msg.sender = lem THEN 24: didExpandOrShrink←msg.value 25: END IF 26: UNTIL didExpandOrShrink OR permutedLL.isEmpty() 27: sleep(time);//pause for few second 28: END LOOP

23. 案例二:無代價情況下的最大限度使用率(3/3) Policy 2.b AutoMax: LEM Policy Procedure 1: /* input parameters: ref to this LEM obj, ref to GEM obj, ref to monitor and ref tothis LEM’s app state table */ 2: INPUT: Lem lem, Gem gem, Monitor m, AppStatTbl ast 3: 4: LOOP 5:Message msg←lem.getMessage(); 6: IF msg.type = expand OR msg.type = shrink THEN 7:/* the application decides its response */ 8: Bool canChange←canExpandOrShrink(msg.type); 9: IF canChange THEN 10: /* the application decides how to expand or shrink */ 11: expandOrShrink(msg.type); 12: END IF 13: gem.sendMessage(changeResponse, canChange) 14:END IF 15: END LOOP

24. 案例三:不犧牲效能的情況下降低功耗(1/4) • 第三個案例，提出一個REEact策略降低系統的功耗。 • 此策略根據以下的觀察: • 如果應用程式沒有使用硬體預抓器 prefetcher，那我們可以在不影響效能的情況下停止使用prefetcher，以減少功耗。 • 利用REEact,我們可以動態地去檢查應用程式如何使用prefetcher • Policy3.a和Policy3.b分別為全域(GEM)和局部(LEM)程式的pseudocode. • 當新執行緒產生時，REEact的執行緒狀態監控器便會發訊息給GEM(Policy 3.a line 6). • 一旦收到訊息，GEM開始測試兩個配置: • Prefetchers enabled • Prefetchers disabled

25. 案例三:不犧牲效能的情況下降低功耗(2/4) • The GEM also notifies the LEMs to collect the number of instructions retired for these two configurations (Policy 3.a lines 7-27). • 每個配置執行0.5秒 and each LEM reportsthe number of instructions retired to GEM (Policy 3.b lines). • The GEM compares the results, and disables the prefetchersif the configuration with enabled prefetchers does not retire moreinstructions (Policy 3.a lines 28-33).

26. 案例三:不犧牲效能的情況下降低功耗(3/4) Policy 3.a REEact Power management: GEM policy procedure 1: /* input parameters: ref to all LEM objs, ref to GEM obj, ref to monitor, ref toGEM’s app state table, ref to HW actuators */ 2: INPUT: List lemList, Gem gem, Monitor m, AppStatTbl ast, HWActuator hwAct 3: Int coreCnt←m.getTotalCoreCount(); 4: LOOP 5:Message msg←gem.getMessage(); 6: IF msg.type = ThreadActivated THEN 7:/* start sampling configuration with prefetchers on*/ 8: /* enable prefetchers on all cores */ 9: hwAct.enableHWComponent(c, prefetcher, on); 10:FOR ALL lem IN lemList DO 11: lem.sendMessage(readInsnRetired, NULL); 12: END FOR 13: Int insnPfOn←0; 14:FOR ALL lem IN lemList DO 15: Message msg←gem.getMessage(); 16: insnPfOn←insnPfOn + msg.value; 17: END FOR 18: /* start sampling configuration with prefetchers off*/ 19: hwAct.enableHWComponent(c, prefetcher, off); 20: FOR ALL lem IN lemList DO 21: lem.sendMessage(readInsnRetired, NULL); 22: END FOR 23: Int insnPfOff←0; 24: FOR ALL lem IN lemList DO 25: Message msg←gem.getMessage(); 26: insnPfOff←insnPfOff + msg.value; 27: END FOR 28: /* Comparing two configuration */ 29: BOOL switch←off; 30: IF insnPfOn > insnPfOff × 1.02 THEN 31: switch←on; 32: END IF 33: hwAct.enableHWComponent(c, prefetcher, switch); 34: END IF 35: END LOOP

27. 案例三:不犧牲效能的情況下降低功耗(4/4) Policy 3.b REEact power management: LEM policy procedure 1: /* input parameters: ref to this LEM obj, ref to GEM obj, ref to monitor and ref tothis LEM’s app state table */ 2: INPUT: Lem lem, Gem gem, Monitor m, AppStatTbl ast 3:List appThreads←ast.getAppThreads(); 4: LOOP 5: Message msg←lem.getMessage(); 6: Double time = 0.5; /* sample for 0.5 seconds */ 7: IF msg.type = readInsnRetired THEN 8: /* read InsnRetired for all the threads of this LEM */ 9: List insnCnts←insnCnt + m.readPMUperThread(appThreads, InsnRetired, time); 10: gem.sendMessage(InsnRetiredValue, insnCnts.sum()); 11:END IF 12:END LOOP

28. 案例三:不犧牲效能的情況下降低功耗(4/4) • 以PrefetcherOn 為正交基準做比較，執行時間、能耗、EDP越小越好。 • EDP: energy-delay-product (EDP) 能量延遲乘積。 圖六、PARSEC benchmarks測試 兩種配置:預取器全開或不開

29. 結論(1/1) • 各種用戶需求、應用程式行為和硬體配置都會大幅增加管理CMP硬體資源和應用的複雜度。 • 管理策略處理這些變化根據特定用戶/應用程式/ 硬體的需求且需要動態的適應。 • 本文解決這些管理問題，透過用戶級別的VEE架構REEact啟用自定義資源管理策略的設計和實施。 • 該架構提供了多種服務進行硬體資源和應用程式的動態管理和協調。