為了使用它們, 盡管你不會需要知道內核定時器如何實現, 這個實現是有趣的, 並且值得 看一下它們的內部.
定時器的實現被設計來符合下列要求和假設:
- 定時器管理必須盡可能簡化.
- 設計應當隨着激活的定時器數目上升而很好地適應.
- 大部分定時器在幾秒或最多幾分鍾內到時, 而帶有長延時的定時器是相當少見.
- 一個定時器應當在注冊它的同一個 CPU 上運行.
由內核開發者想出的解決方法是基於一個每-CPU 數據結構. 這個 timer_list 結構包括 一個指針指向這個的數據結構在它的 base 成員. 如果 base 是 NULL, 這個定時器沒有 被調用運行; 否則, 這個指針告知哪個數據結構(並且, 因此, 哪個 CPU )運行它. 每- CPU 數據項在第 8 章的"每-CPU 變量"一節中描述.
無論何時內核代碼注冊一個定時器( 通過 add_timer 或者 mod_timer), 操作最終由 internal_add_timer 進行( 在 kernel/timer.c), 它依次添加新定時器到一個雙向定時器 鏈表在一個關聯到當前 CPU 的"層疊表" 中.
這個層疊表象這樣工作: 如果定時器在下一個 0 到 255 jiffies 內到時, 它被添加到專 供短時定時器 256 列表中的一個上, 使用 expires 成員的最低有效位. 如果它在將來更 久時間到時( 但是在 16,384 jiffies 之前 ), 它被添加到基於 expires 成員的 9 - 14 位的 64 個列表中一個. 對於更長的定時器, 同樣的技巧用在 15 - 20 位, 21 - 26 位, 和 27 - 31 位. 帶有一個指向將來還長時間的 expires 成員的定時器( 一些只可能發生 在 64-位 平台上的事情 ) 被使用一個延時值 0xffffffff 進行哈希處理, 並且帶有在過
去到時的定時器被調度來在下一個時鍾嘀噠運行. (一個已經到時的定時器模擬有時在高 負載情況下被注冊, 特別的是如果你運行一個可搶占內核).
當觸發 run_timers, 它為當前定時器嘀噠執行所有掛起的定時器. 如果 jiffies 當前 是 256 的倍數, 這個函數還重新哈希處理一個下一級別的定時器列表到 256 短期列表, 可能地層疊一個或多個別的級別, 根據 jiffies 的位表示.
這個方法, 雖然第一眼看去相當復雜, 在幾個和大量定時器的時候都工作得很好. 用來管 理每個激活定時器的時間獨立於已經注冊的定時器數目並且限制在幾個對於它的 expires 成員的二進制表示的邏輯操作上. 關聯到這個實現的唯一的開銷是給 512 鏈表頭的內存 ( 256 短期鏈表和 4 組 64 更長時間的列表) -- 即 4 KB 的容量.
函數 run_timers, 如同 /proc/jitimer 所示, 在原子上下文運行. 除了我們已經描述 過的限制, 這個帶來一個有趣的特性: 定時器剛好在合適的時間到時, 甚至你沒有運行一 個可搶占內核, 並且 CPU 在內核空間忙. 你可以見到發生了什么當你在后台讀
/proc/jitbusy 時以及在前台 /proc/jitimer. 盡管系統看來牢固地被鎖住被這個忙等待 系統調用, 內核定時器照樣工作地不錯.
但是, 記住, 一個內核定時器還遠未完善, 因為它受累於 jitter 和 其他由硬件中斷引 起怪物, 還有其他定時器和其他異步任務. 雖然一個關聯到簡單數字 I/O 的定時器對於 一個如同運行一個步進馬達或者其他業余電子設備等簡單任務是足夠的, 它常常是不合適 在工業環境中的生產系統. 對於這樣的任務, 你將最可能需要依賴一個實時內核擴展.