5. 異質雙核心動態分工排程器實作
5.1. Scheduler API
這個介面提供 scheduler 使用上的便利性。Scheduler API 是新的 system
scheduler Dispatcher
Service Registrar service Service Registrar 就會回覆之。
圖中 eCos kernel API 和 DSP API 是同一研究團隊成員 eCos kernel
HAL interface/HAL API
MLQ
GPP DSP
call，它的目標就是令使用者在移植單核心的應用程式為異質雙核心應用程式 時，只需做最小的修改，便能使用 scheduler。因此 Scheduler Interface 提供兩類 三個系統呼叫的程式，它們是註冊和執行這兩類：
P_remove_service()歸屬於註冊類。它們扮演 的功能是向 為 dual-core service 或是移除之。一旦註冊了 某項 service 為 dual-core service，之後使用這個 service 時，就會被引入 HMP scheduler，由 GPP 或由 DSP 負責執行都有可能。使用 service 的方法，在註冊後，
HMP Scheduler API 會 給 使 用 者 一 個 ID 。 使 用 service 就 要 呼 叫 HMP_invoke_service()，填入 ID 指定註冊的 service 和填入原 service 的參數。
HMP_invoke_service()被設計為可容納不同數量參數的介面，因此各種數量參數 皆可以處理。舉一個簡單的例子，在之後的實驗裡，測試的應用程式為 H. 263 decoder。圖 11 中 Idct 是 decoder 其中一個程式，接受的參數是一個 short。欲使 用 HMP scheduler 只需把程式改為圖 12 的寫法。
Figure 11. 一般單核心 idct 函數的使用方法 z HMP_register_service()
z HMP_invoke_service() z HMP_remove_service() HMP_register_service()和 HM
kernel 註冊某項 service
void idct(short *block) { … }
void main() { …
idct(block);
… }
Idct 程 式 不 必 做 任 何 修 改 。 在 主 程 式 中 呼 叫 idct 之 前 ， 先 用 HMP_register_service(idct_image)註冊取得 id。之後要使用 idct 就改呼叫 idct(block) 為呼叫 HMP_invoke_service(id, block)。id 是向 kernel 取得的資料，而 block 是原 本主程式的指標資料。全部就只要做到這些修改，應用程式幾乎看不到有單核心 雙核心程式的不同，移植的便利性非常大。
uler 下 idct 使用方法
OMAP 屬於雙核心的晶片，因此 HMP Scheduler 在執行排程工作 之外，要負責 當然 DSP 的啟動可以在 booting 時完成，考量並非 每一種應用程式都需要用到 DSP，只在 HMP Scheduler 被啟動時才自動啟動 DSP，以減少 ng 的 overhead。另外有一個做法也是可以實行的，那就是將
DSP 啟動 uler 時，要先下
該指令啟動 D
void idct(short *data) { … }
HMPHMP_invoke_service(id, block);
…
Figure 12. HMP sched 5912 是
DSP 的啟動。
booti
轉換成 bootstrap (Redboot)的指令，欲使用 HMP Sched SP，再執行應用程式。
5.2. S
pointer
到所需資訊的 Service Registrar 開始進行註冊動作。首先在 core service
。接 binary image 傳入 DSP
internal RAM，完成之後向 DSP 註冊該 service，得到 DSP 回傳的 service DSP ID。
在 core
ter 會改成 ARM 的 image。ARM 的 image 和 DSP 的 image 會包 成一個資
完 一個 service kernel ID，回傳給應
用程式。Service kernel ID 和 service DSP ID 是不同的。前者是應用程式和 kernel 互動時，用來指明 service 的依據。應用程式要執行 service 時，若 Dispatcher 判 斷該 service 為 GPP 執行，kernel 會根據 service kernel ID 到 core service table 找 到正確的 function pointer，由 GPP 端執行 service；若 service 被判斷為 DSP 執行，
kernel 依 service kernel ID 在 core service table 內找對應的 service DSP ID。在通知 DSP 執行某個 service 時，一併傳入 service DSP ID，如此一來 DSP 便了解該執 行哪一個 service。所以 service kernel ID 和 service DSP ID 是完全不相同。
Service Register 另外一項功能為移除 service。接受移除指令的 Service Register 會自 core service table 中移除紀錄。並將 service image 從 DSP 內移除。
Dispatcher 負責在應用程式要求執行 dual-core service 之後，判斷由哪一
ervice Registrar 和 Core Service Table
應用程式向 Service Registrar 註冊 service，Service Registrar 收到 service 的資訊如下：
z Service function pointer z Service DSP binary image 得
table 內紀錄 function pointer 著透過 DSP API 將 DSP
service table 紀錄此 ID。之後都用此 ID 向 DSP 做指定 service 的動作。未 來 function poin
料結構。
成上述程序的 Service Registrar 會產生
5.3. Dispatcher
顆處理器來執行會得到最短的執行時間，進而決定由哪一顆處理器執行。判斷由 GPP 執行，就直接將 service 交給 MLQscheduler，依原本 eCos kernel 的路徑執行，
但結束時會有些許改變；或是由 DSP 執行該 service。Dispatcher 的架構圖如下：
Termin
Interfac 一旦 Task 資訊，會喚醒
Calculator。 co 傳 Cost value 給 Task
Dispatcher。Task Dispatcher 就以 cost value 判定由哪一處理器執行 service。Task Dispatcher 判定 service 的執行處理器，在屬於該處理器的 loading table 新增 service loading 資料。只要 service 執行完畢，就
括通知應用程式 service g table 移除紀錄。由
loading
Figure 13. Dispatcher 架構圖
Dispatcher 是 由 三 大 單 元 組 成 ， 它 們 分 別 是 Task Dispatcher 、 Task ator、和 loading tables。執行 dual-core service 的資訊經 HMP Scheduler
e 傳入 Dispatcher 。 Dispatcher 接 收 到 Cost Cost Calculator 開始計算 st value，接著便回
由 Task Terminator 來結束整個程序，包 執行完成，和自處理器的 loadin
table 的觀點來看，其 producer 是 Task Dispatcher，而 Task Terminator 為 consumer。此外，當 service 必須對大量資料做運算使用到 pointer，而此 service 為被決定為 DSP 執行時，Dispatcher 得負責 DSP 可以得到整筆資料，之後有段 落會專門介紹 Dispatcher 如何令 DSP 得到完整資料的實作方式。
Task Dispatcher Cost Calculator
5.3.1. Task Dispatcher
Task Dispatcher 得自應用程式的 service ID 是 service kernel ID。Task Dispatcher 的工作主要是依處理器的 loading 狀態，分配 service 給某一顆處理器 負責執行，我們所使用的動態排程方式，基本上是根據過去的執行狀態來預測何 者未來的 loading 比較低，便將工作交由該處理器執行。Task Dispatcher 會從 Cost Calculator 得到被呼叫的 service 在不同處理器所需的執行時間的估測，分別記錄 在 time_ARM_prediction 和 time_DSP_prediction 這兩個變數中。此動態排程的判 斷方法是將估測出的時間相比，來決定誰該執行該工作：
z time_ARM_prediction > time_DSP_prediction： service 判定給
在相等的情況下，service 會由 DSP 負責執行。其原因在於本平台系統專 為處理多媒體資料而設計，dual-core service 都是數位訊號處理的形式，在 DSP 和 ARM 的速度和耗電力比較，和忽略雙核心溝通的 overhead 的前提之下，DSP 更適合擔
在 Cost Calculator 的部份，是利用指數平均數(exponential average)的方法 來預測 se ce
DSP 執行。
z time_ARM_prediction < time_DSP_prediction： service 判定給 ARM 執行。
z time_ARM_prediction = time_DSP_prediction： service 判定給 DSP 執行。
t : n 上一次實際執行時間。
一般情況下，也許有時候 DSP 慢一點而 ARM 又快一點，Cost Calculator 結果是 ARM 較小，該 idct 就由 AR ；如果又回到 DSP 快的情況下，
500 time tick 2000 time tick DSP idct，也不會更新tn和Tn。這麼一來，系統上的
經過實驗當預測值被除以 2 之後，公式改變如下。每次新值就會依 0.85 器 loading table 增加 service 紀錄，和更新處理器全部執行時間。接著交付 service 給處理器執行。
5.3.2. Task Terminator
Task Dispatcher 和 Task Ter inator 在系統中的角色是相反的。它接受 ARM 或是 DSP 結束 service 執行的訊息，自 service loading table 移除 service 紀錄，和 更新處理器全部執行時間。下一步再通知應用程式＂己經完成 service＂。
5.3.3. Loading Tables
Loading table 用來紀錄各處理器的 loading 狀態，和各處理器上執行的 services。意義上 ARM(DSP) service table 是紀錄 service 種類，而 ARM(DSP)
理器上正在執行的 service。換句話說，同一種 service 種類在
m
loading table 是紀錄每一個處
ARM(DSP) service table 只有一筆資料，但在 ARM(DSP) loading table 上，
只要應用程式對同一種 service 要求執行幾次，同一種 service 種類就會有幾筆資 料，可是這些資料互相是不同。圖 14 為 loading table 的結構：
Figure 14. Loading table
Loading table 分為 header node 和 common node。Header node 紀錄其負責 上所
處理器 數 k number) 時 。
未來我們會增加不同 cost function 考慮的因素，概括說來是不同種類的核心 loading 狀態，如電力消耗。在 header node 預留一些欄位可以用來記錄新增的
loading 狀態。每一個 com ，紀錄著在 loading
table 上
的組合。 上有四組 ，
其中兩組為 ，另兩組為 。顧名思義， 為
發給 的 mailbox，DSP to ARM 是 DSP 發給 ARM 的 mailbox。每組 mailbox 上有兩個 16 位元 register，一個設定為 command register，另一個為 data
Total time
mon node 代表一個執行中的 service
的位置(index)、執行時間(execution time)、和名稱(service name)。這是一 個 double direction linked list 資料結構，有鑑於不同的 service 有不同的執行時間，
亦即 service 加入 table 的順序不會和離開 table 的順序相同，使用 linked list 處理 這個特性。
5.4. 雙核心溝通方法
使用 mailbox 和 shared memory OHMP 5912 mailbox ARM to DSP DSP to ARM ARM to DSP
ARM DSP
register。在 ARM to DSP mailbox 上，ARM 有完全的讀寫權利，DSP 只有讀取的 權限；反之亦然。ARM 填完第二個 register 時，硬體會自動設定一個 flag，因此 DSP 會
設計三種 ARM to DSP mailbox action command，如下：
z Register service。
ailbox action command，是 ARM to DSP 的回應指令如 下：
rvice 註冊。
ervice 執行。
移除。
service image 放入 DSP space internal RAM。完成註冊動作，DSP 會回 return
register m r 儲存 service DSP ID。再由
Service Reg strar table ，但功能相反是 remove。
最後一種指令為 指令。 command register 填入 invoke 指令，
data register 填入自 DSP service table 取得的 service DSP ID。依此行為 DSP 便會 開始執行要求的 service。著眼於 mailbox 只提供兩個 16 位元的 register，沒有辦 法利用 mailbox 傳入其它參數或資料。為了解決這個問題，shared memory 正可 派上用場。Shared memory 指得是 OMAP 5912 on-chip SRAM，共有 250 k-byte 有 interrupt 產生。DSP 開始讀取兩個 register 的資料，讀完第二個 register 之後，flag 會再由硬體設回 0，表示 DSP 讀取完畢。利用 mailbox 傳遞做為雙核
ARM 發 register mailbox action command 註冊 service 之前，ARM 利用 DSP API 把
ailbox action command，並利用 data registe i 存入 DSP service 。相同的運做模式
invoke ARM 在
可以使用。設計了 parameter table，結構如下：
Figure 15. Parameter table
Parameter 1 到 parameter 4 位元組。接下來 source data 及 destination data 每一個佔 4000 位 大記憶體是選擇性使用，如果使用 這兩塊記憶體，可以利用前面的 eter 2 分別指到 source data 和 destination data。給應用程式設計者很大的彈性空間。如前述 H.263 idct(short block)的例子，可以把整個 ck p 搬到 source data，把 Parame
DSP_address = (ARM_address – ARM_base_address) / 2 + DSP_base_address
因此 ARM 在選擇 parameter table 的起始位址，必需在 16 位元制下以 0、
4、8、或 C 結尾。DSP 才能正確讀取。否則會有不可預期的錯誤。
4，每一個佔用 元組。這兩塊
parameter 1 或 param
short blo 從 ARM 的 hea
ter 1 指到 source data，並另用 Parameter 2 指定一塊記憶體。DSP 端的 idct.image 就可以從 Parameter 1 拿到整筆資料，運算完畢後，再將結果存到 Parameter 2 指到的位置。
每一個 service 會有一份此 parameter table。使用完之後可立即釋放記憶體 空 間 。 ARM 的 定 址 模 式 為 byte addressing ， 而 DSP 的 定 址 模 式 為 word addressing(每個 word 2 bytes)。兩種位址的轉換如下：
5.5. DSP API
表 6 簡介 DSP API 的名稱與其功能。
Table 6. DSP API API name description
dsp_init() 啟動 DSP 處理器 dspmmu_for_sdram() 啟動 DSP MMU pmem_init() 啟動 DSP internal ram pmem_allocate() 取得 DSP internal ram pmem_free() 釋放 DSP internal ram
這部份的 的 real-tim
研究生負責，因此不在這邊討論其細部設計。
設計是配合 DSP e kernel 設計的，是由本實驗室另一位
6. 實驗結果
本論文一直闡述想的法在第五章介紹了實作的過程。在這一章將會做五組不 同的實驗來驗證 HMP Scheduler 的動態排程功能和系統效能。首先我們會介紹實 驗的環境，接著再介紹各組實驗，包括實驗的方法和討論。
6.1. 實驗環境
在這一段落先介紹實驗使用的的應用程式，它是 H.263 的 decoder。 H.263 decoder 是用來將己經壓製好的 m4v 檔案解回 yuv 檔案。主要的 function 也就是
在這一段落先介紹實驗使用的的應用程式，它是 H.263 的 decoder。 H.263 decoder 是用來將己經壓製好的 m4v 檔案解回 yuv 檔案。主要的 function 也就是