slacks 和 idle 的利用與搜集

首先對slack的定義再說明:slack是指task實際完成的時間到WCET之間的時間。

而idle則是兩task之間的空閒時間。 在某些情況下slack也可以視作idle。

下面以數學式與圖型說明:

圖 4.7 slack

上圖為突顯slack與idle的時間在觀念上的不同，因此taskⁱ與taskⁱ⁺¹之間是緊緊相連 的，假設taski的deadline與taski+1的arrive time是相同的。 然而slack會依task執行 的狀況而有所不同，在第三章中已討論過它的機率模型，在此將不再贅述。

此外在Inter-Task的演算法中，slack的再利用基本上是給下個task使用的，因此，意 味著若要執行下一個Task將會有調節的機會。所以，需要調節與否將視所剩餘的時間是 否足夠轉換的耗損所需。

至於idle方面，可由圖 4.8做清楚的認知與定義。 Idle是指OS目前並沒有任何task在 執行，CPU是處於閒置的狀態。

圖 4.8 idle

圖 4.8 的idle為兩個task在時間上並沒有任何的重疊，這段沒有工作的時間就是idle time，目前較常見的CPU幾乎都有專門提供idle的工作模式，idle的工作模式下，CPU是 處於較省電的狀態。 因此，能夠獲得較長的idle模式也是電源管理的重點之一。而Idle 與slack不同，idle發生時當然可以利用idle的時間將電壓和操作頻率降到最低。但是 在下一個task來到之後將再需要一次的調節，所以在idle時間做調整將需要兩次調節的 時間。

其次，slack和idle也有混合的情況出現。

圖 4.9 Idle 與 slack 的混合狀態

圖4.9 是一種混合的狀態，結合著slack與真正的idle時間而成。 有了上述這三種空閒 的情況。因此，電壓調整的策略可以充份的利用這些空閒的時間做調整且降低或不會對 工作造成即時性的危害。

首先，只有slack的情況，由於slack的發生和時間的長度是具機率性質。因此，運用方 面先視它的長度及下一task的工作需要做調整。所以，有下面幾種情況:

slack>overhead，且下一工作的需求是升壓與升頻。那麼scheduler可以將CPU進入idle 模式，直到aⁱ⁺¹-overhead的時間後開始升頻，如圖4.10(a)所示。

slack>overhead，且下一工作的需求是降壓與降頻。那麼scheduler可以將先降壓降頻 然後再進入idle模式，如圖4.10(b)所示。

圖 4.10 利用 slack 做升降壓

slack<overhead， 且下一工作為升壓與升頻。 那麼scheduler將立刻升壓升頻。

slack<overhead， 且下一工作為降壓與降頻。 那麼還要計算調節佔用多少的工作時間，

並且如果仍需降頻則立刻降頻，若是無法降頻則使用原來的狀態進入idle模式。此外，

若下一個task的WCET小於overhead那麼也將保持原來的狀態。以免得不嘗失。

Idle時間方面，若task queue內已有task待處理，基本上考慮的方式與slack是一樣的 考慮方式。 若是task queue內沒有task在等待處理那麼只能直接進入idle模式，然後 視需要再加以調整。

圖 4.11 運用 idle 與 slack 做調整

圖4.11 (a)說明了idle或 slack時間不足時會佔用到task的執行時間。 圖4.11(b)則說 明了slack和idle的運用。

基於上述的情況可知，動態排程和靜態排程最大的不同就是對予slack的預測，在本報 告中提出一個方法，其方法的基本概念是從「應用導向」來增加slack預測的正確性。

「應用導向」是指應用程式在執行時，基本上都有一定的脈絡可循。例如:一個MP3的撥 放程式其動作大體上為讀取MP3檔案內容、解碼、撥放等一直重覆的動作。

因此，在動態排程時最主要的一個限制就是下一個工作不知何時會產生。因此，如果能 夠知道下一個工作或完整的工作串列，那麼處理動態排程將跟靜態排程一樣的準確。

在本報告中以雙向指標的資料結構利用context switch時將指標分別指向其上下TASK，

以建立上下游的關係，如此一來當下一回合又進入此TASK時，將能夠知道下一個工作的 參數，以增加slack預測的準確性。