linux內核定時器struct timer_list

     內核中最終的計時資源是定時器。定時器用於定時器超時處理程序在未來某個特定時間點執行，或者週期性的輪詢硬件的狀態。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 的定時器對於一個如同運行一個步進馬達或者其他業餘電子設備等簡單任務是足夠的, 它常常是不合適在工業環境中的生產系統. 對於這樣的任務, 你將最可能需要依賴一個實時內核擴展.