5. 異質雙核心動態分工排程器實作
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 處理 這個特性。