核心中最終的計時資源是定時器。定時器用於定時器超時處理程式在未來某個特定時間點執行，或者週期性的輪詢硬體的狀態。Linux提供了核心定時器完成這類工作。
    定時器的只需要執行一些初始化的操作，如：設定一個超時時間，指定超時要呼叫的函式，然後啟用定時器就可以了。它的處理和工作佇列還是有點類似的。和任務佇列一樣，核心定時器並不是週期執行，它在超時後自動銷燬。因此，如果要實現週期輪詢，就需要在定時器執行函式返回前再次啟用定時器。

    一般來說，定時器都在超時後馬上就會執行超時處理函式，但是也有可能被推遲到下一個時鐘節拍時才能執行，所以不能用定時器來實現任何硬實時任務。

    核心定時器用於控制某個函式(定時器處理函式)在未來的某個特定的時間執行。核心定時器註冊的處理函式只執行一次，不迴圈執行

    核心定時器被組織成雙向連結串列，並使用struct timer_list結構描述
struct timer_list{
 struct list_head entry; //核心使用
 unsigned long exoires; //設定的超時的值
 void(*function)(unsigned long); //超時處理函式
 unsigned long data; //超時處理函式引數
 struct tvec_base *base; //核心使用
}

下面看看一個實現輪詢操作的小例子：

struct timer_list polling_timer;

init_timer(&polling_timer);
polling_timer.data = (unsigned long)something;
polling_timer.function = polling_handler;
polling_timer.expires = jiffies + 2 * HZ;
add_timer(&polling_timer);

void polling_handler(unsigned long data) {
...
polling_timer.expires = jiffies + 2 * HZ;
add_timer(&polling_timer);

}

    jiffies是Linux核心中的一個全域性變數，用來記錄自系統啟動以來產生的節拍的總數。啟動時，核心將該變數初始化為0，此後，每次時鐘中斷處理程式都會增加該變數的值。因為一秒內時鐘中斷的次數等於HZ，所以jiffies一秒內增加的值也就為HZ。系統執行時間以秒為單位計算，就等於jiffies/HZ。

    節拍率HZ是通過靜態預處理定義的，在系統啟動時按照HZ值對硬體進行設定。體系結構不同，HZ值就不同，在i386體系結構在include/asm-i386/param.h中定義如下：
#define HZ 1000

每秒鐘時鐘中斷1000次，也就是說，在1秒裡jiffies會被增加1000。因此jiffies + 2 * HZ表示推後2秒鐘。

void init_timer(struct timer_list *timer);

該函式用來初始化定時器結構，其實它只將prev和next指標清零；

void add_timer(struct timer_list *timer);

該函式將定時器插入活動定時器的全域性佇列中，即啟用定時器；

void mod_timer(&polling_timer, jiffies + new_delay);

需要更改已經啟用的定時器的超時時間，則呼叫上面函式；

del_timer(&polling_timer);

如果需要在定時器超時前將定時器從連結串列中刪除，則呼叫上面函式。注意：定時器超時後，系統會自動刪除定時器，則不用呼叫上面函式。

在多處理器的情況下使用：del_timer_sync(&polling_timer);和del_timer函式類似，不同的是該函式確保在它返回時，定時器函式不在任何CPU上執行，大多數情況下使用該函式。再次注意：不需要為已經超時的定時器呼叫該函式，因為系統會自動刪除。在已經從連結串列刪除的定時器上呼叫del_timer()或del_timer_sync()沒什麼害處，所以說從定時器函式中刪除定時器是一種很好的習慣。

    核心定時器是在時鐘中斷髮生後，作為軟中斷在下半部的上下文中執行的。所有的定時器結構都以連結串列的形式儲存。時鐘中斷髮生後，核心按連結串列順序依次執行。因為核心定時器發生在軟中斷中，因此，定時器執行函式不能夠睡眠，也不能夠持有訊號量。如果對硬體的訪問需要使用訊號量同步，或者可能睡眠（比如需要呼叫kmalloc記憶體分配，但是由於某種原因不能使用GFP_ATOMIC標誌），就不能直接通過定時器來實現了。一個變通的做法是在核心定時器執行函式裡呼叫工作佇列，在工作佇列處理函式中實現對硬體的訪問。

----------------------------------------------------------------------------------------------

無論何時你需要排程一個動作以後發生, 而不阻塞當前程序直到到時, 核心定時器是給你的工具.這些定時器用來排程一個函式在將來一個特定的時間執行, 基於時鐘嘀噠, 並且可用作各類任務;例如, 當硬體無法發出中斷時, 查詢一個裝置通過在定期的間隔內檢查它的狀態. 其他的核心定時器的典型應用是關閉軟碟機馬達或者結束另一個長期終止的操作. 在這種情況下, 延後來自 close 的返回將強加一個不必要(並且嚇人的)開銷在應用程式上. 最後, 核心自身使用定時器在幾個情況下, 包括實現 schedule_timeout.
    一個核心定時器是一個數據結構, 它指導核心執行一個使用者定義的函式使用一個使用者定義的引數在一個使用者定義的時間. 這個實現位於 <linux/timer.h> 和 kernel/timer.c 並且在"核心定時器"一節中詳細介紹.
被排程執行的函式幾乎確定不會在註冊它們的程序在執行時執行. 它們是, 相反, 非同步執行. 直到現在, 我們在我們的例子驅動中已經做的任何事情已經在執行系統呼叫的程序上下文中執行. 當一個定時器執行時, 但是, 這個排程程序可能睡眠, 可能在不同的一個處理器上執行, 或者很可能已經一起退出.
    這個非同步執行類似當發生一個硬體中斷時所發生的( 這在第 10 章詳細討論 ). 實際上, 核心定時器被作為一個"軟體中斷"的結果而實現. 當在這種原子上下文執行時, 你的程式碼易受到多個限制. 定時器函式必須是原子的以所有的我們在第 1 章"自旋鎖和原子上下文"一節中曾討論過的方式, 但是有幾個附加的問題由於缺少一個程序上下文而引起的. 我們將介紹這些限制; 在後續章節的幾個地方將再次看到它們. 迴圈被呼叫因為原子上下文的規則必須認真遵守, 否則系統會發現自己陷入大麻煩中.
為能夠被執行, 多個動作需要程序上下文. 當你在程序上下文之外(即, 在中斷上下文), 你必須遵守下列規則:
● 沒有允許存取使用者空間. 因為沒有程序上下文, 沒有和任何特定程序相關聯的到使用者空間的途徑.
● 這個 current 指標在原子態沒有意義, 並且不能使用因為相關的程式碼沒有和已被中斷的程序的聯絡.
● 不能進行睡眠或者排程. 原子程式碼不能呼叫 schedule 或者某種 wait_event, 也不能呼叫任何其他可能睡眠的函式. 例如, 呼叫 kmalloc(..., GFP_KERNEL) 是違犯規則的. 旗標也必須不能使用因為它們可能睡眠.核心程式碼能夠告知是否它在中斷上下文中執行, 通過呼叫函式 in_interrupt(), 它不要引數並且如果處理器當前在中斷上下文執行就返回非零, 要麼硬體中斷要麼軟體中斷.一個和 in_interrupt() 相關的函式是 in_atomic(). 它的返回值是非零無論何時排程被禁止; 這包含硬體和軟體中斷上下文以及任何持有自旋鎖的時候. 在後一種情況, current 可能是有效的, 但是存取使用者空間被禁止, 因為它能導致排程發生. 無論何時你使用 in_interrupt(), 你應當真正考慮是否in_atomic 是你實際想要的. 2 個函式都在 <asm/hardirq.h> 中宣告.
核心定時器的另一個重要特性是一個任務可以註冊它本身在後面時間重新執行. 這是可能的, 因為每個 timer_list 結構在執行前從啟用的定時器連結串列中去連線, 並且因此能夠馬上在其他地方被重新連線. 儘管反覆重新排程相同的任務可能表現為一個無意義的操作, 有時它是有用的. 例如, 它可用作實現對裝置的查詢.
也值得了解在一個 SMP 系統, 定時器函式被註冊時相同的 CPU 來執行, 為在任何可能的時候獲得更好的快取區域性特性. 因此, 一個重新註冊它自己的定時器一直執行在同一個 CPU.
    不應當被忘記的定時器的一個重要特性是, 它們是一個潛在的競爭條件的源, 即便在一個單處理器系統. 這是它們與其他程式碼非同步執行的一個直接結果. 因此, 任何被定時器函式存取的資料結構應當保護避免併發存取, 要麼通過原子型別( 在第 1 章的"原子變數"一節) 要麼使用自旋鎖( 在第 9 章討論 ).
7.4.1. 定時器 API
核心提供給驅動許多函式來宣告, 註冊, 以及去除核心定時器. 下列的引用展示了基本的程式碼塊:
#include <linux/timer.h>
struct timer_list
{
    unsigned long expires;
    void (*function)(unsigned long);
    unsigned long data;
};
void init_timer(struct timer_list *timer);
struct timer_list TIMER_INITIALIZER(_function, _expires, _data);
void add_timer(struct timer_list * timer);
int del_timer(struct timer_list * timer);
這個資料結構包含比曾展示過的更多的欄位, 但是這 3 個是打算從定時器程式碼自身以外被存取的.
這個 expires 欄位表示定時器期望執行的 jiffies 值; 在那個時間, 這個 function 函式被呼叫使用 data 作為一個引數. 如果你需要在引數中傳遞多項, 你可以捆綁它們作為一個單個數據結構並且傳遞一個轉換為 unsiged long 的指標, 在所有支援的體系上的一個安全做法並且在記憶體管理中相當普遍( 如同 15 章中討論的 ). expires 值不是一個 jiffies_64 項因為定時器不被期望在將來很久到時, 並且 64-位操作在 32-位平臺上慢.
    expire這個結構必須在使用前初始化. 這個步驟保證所有的成員被正確建立, 包括那些對呼叫者不透明的. 初始化可以通過呼叫 init_timer 或者 安排 TIMER_INITIALIZER 給一個靜態結構, 根據你的需要. 在初始化後, 你可以改變 3 個公共成員在呼叫 add_timer 前. 為在到時前禁止一個已註冊的定時器, 呼叫 del_timer.
jit 模組包括一個例子檔案, /proc/jitimer ( 為 "just in timer"), 它返回一個頭檔案行以及 6 個數據行. 這些資料行表示當前程式碼執行的環境; 第一個由讀檔案操作產生並且其他的由定時器. 下列的輸出在編譯核心時被記錄:
phon% cat /proc/jitimer
time delta inirq pid cpu command
33565837 0 0 1269 0 cat
33565847 10 1 1271 0 sh
33565857 10 1 1273 0 cpp0
33565867 10 1 1273 0 cpp0
33565877 10 1 1274 0 cc1
33565887 10 1 1274 0 cc1
    在這個輸出, time 欄位是程式碼執行時的 jiffies 值, delta 是自前一行的 jiffies 改變值, inirq 是由
in_interrupt 返回的布林值, pid 和 command 指的是當前程序, 以及 cpu 是在使用的 CPU 的數目( 在單處理器系統上一直為 0).
    如果你讀 /proc/jitimer 當系統無負載時, 你會發現定時器的上下文是程序 0, 空閒任務, 它被稱為"對換程序"只要由於歷史原因.
    用來產生 /proc/jitimer 資料的定時器是預設每 10 jiffies 執行一次, 但是你可以在載入模組時改變這個值通過設定 tdelay ( timer delay ) 引數.
    下面的程式碼引用展示了 jit 關於 jitimer 定時器的部分. 當一個程序試圖讀取我們的檔案, 我們建立這個定時器如下:
unsigned long j = jiffies;
data->prevjiffies = j;
data->buf = buf2;
data->loops = JIT_ASYNC_LOOPS;
data->timer.data = (unsigned long)data;
data->timer.function = jit_timer_fn;
data->timer.expires = j + tdelay;
add_timer(&data->timer);

wait_event_interruptible(data->wait, !data->loops);
The actual timer function looks like this:
void jit_timer_fn(unsigned long arg)
{
    struct jit_data *data = (struct jit_data *)arg;
    unsigned long j = jiffies;
    data->buf += sprintf(data->buf, "%9li %3li %i %6i %i %s\n",j, j - data->prevjiffies, in_interrupt() ? 1 : 0,current->pid, smp_processor_id(), current->comm);
    if (--data->loops) {
        data->timer.expires += tdelay;
        data->prevjiffies = j;
        add_timer(&data->timer);
    } else {
        wake_up_interruptible(&data->wait);
    }
}
定時器 API 包括幾個比上面介紹的那些更多的功能. 下面的集合是完整的核提供的函式列表:
int mod_timer(struct timer_list *timer, unsigned long expires);
更新一個定時器的超時時間, 使用一個超時定時器的一個普通的任務(再一次, 關馬達軟碟機定時器是一個典型例子). mod_timer 也可被調用於非啟用定時器, 那裡你正常地使用 add_timer.
int del_timer_sync(struct timer_list *timer);
如同 del_timer 一樣工作, 但是還保證當它返回時, 定時器函式不在任何 CPU 上執行.
del_timer_sync 用來避免競爭情況在 SMP 系統上, 並且在 UP 核心中和 del_timer 相同. 這個函式應當在大部分情況下比 del_timer 更首先使用. 這個函式可能睡眠如果它被從非原子上下文呼叫, 但是在其他情況下會忙等待. 要十分小心呼叫 del_timer_sync 當持有鎖時; 如果這個定時器函式試圖獲得同一個鎖, 系統會死鎖. 如果定時器函式重新註冊自己, 呼叫者必須首先確保這個重新註冊不會發生; 這常常同設定一個" 關閉 "標誌來實現, 這個標誌被定時器函式檢查.
int timer_pending(const struct timer_list * timer);

返回真或假來指示是否定時器當前被排程來執行, 通過呼叫結構的其中一個不透明的成員.
7.4.2. 核心定時器的實現
為了使用它們, 儘管你不會需要知道核心定時器如何實現, 這個實現是有趣的, 並且值得看一下它們的內部.
定時器的實現被設計來符合下列要求和假設:
● 定時器管理必須儘可能簡化.
● 設計應當隨著啟用的定時器數目上升而很好地適應.
● 大部分定時器在幾秒或最多幾分鐘內到時, 而帶有長延時的定時器是相當少見.
● 一個定時器應當在註冊它的同一個 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,384jiffies 之前 ), 它被新增到基於 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 的定時器對於一個如同執行一個步進馬達或者其他業餘電子裝置等簡單任務是足夠的, 它常常是不合適在工業環境中的生產系統. 對於這樣的任務, 你將最可能需要依賴一個實時核心擴充套件.