7.4. 內核定時器

7.4.?內核定時器

無論何時你需要調度一個動作以后發(fā)生, 而不阻塞當前進程直到到時, 內核定時器是給你的工具. 這些定時器用來調度一個函數(shù)在將來一個特定的時間執(zhí)行, 基于時鐘嘀噠, 并且可用作各類任務; 例如, 當硬件無法發(fā)出中斷時, 查詢一個設備通過在定期的間隔內檢查它的狀態(tài). 其他的內核定時器的典型應用是關閉軟驅馬達或者結束另一個長期終止的操作. 在這種情況下, 延后來自 close 的返回將強加一個不必要(并且嚇人的)開銷在應用程序上. 最后, 內核自身使用定時器在幾個情況下, 包括實現(xiàn) schedule_timeout.

一個內核定時器是一個數(shù)據(jù)結構, 它指導內核執(zhí)行一個用戶定義的函數(shù)使用一個用戶定義的參數(shù)在一個用戶定義的時間. 這個實現(xiàn)位于 <linux/timer.h> 和 kernel/timer.c 并且在"內核定時器"一節(jié)中詳細介紹.

被調度運行的函數(shù)幾乎確定不會在注冊它們的進程在運行時運行. 它們是, 相反, 異步運行. 直到現(xiàn)在, 我們在我們的例子驅動中已經(jīng)做的任何事情已經(jīng)在執(zhí)行系統(tǒng)調用的進程上下文中運行. 當一個定時器運行時, 但是, 這個調度進程可能睡眠, 可能在不同的一個處理器上運行, 或者很可能已經(jīng)一起退出.

這個異步執(zhí)行類似當發(fā)生一個硬件中斷時所發(fā)生的( 這在第 10 章詳細討論 ). 實際上, 內核定時器被作為一個"軟件中斷"的結果而實現(xiàn). 當在這種原子上下文運行時, 你的代碼易受到多個限制. 定時器函數(shù)必須是原子的以所有的我們在第 1 章"自旋鎖和原子上下文"一節(jié)中曾討論過的方式, 但是有幾個附加的問題由于缺少一個進程上下文而引起的. 我們將介紹這些限制; 在后續(xù)章節(jié)的幾個地方將再次看到它們. 循環(huán)被調用因為原子上下文的規(guī)則必須認真遵守, 否則系統(tǒng)會發(fā)現(xiàn)自己陷入大麻煩中.

為能夠被執(zhí)行, 多個動作需要進程上下文. 當你在進程上下文之外(即, 在中斷上下文), 你必須遵守下列規(guī)則:

• 沒有允許存取用戶空間. 因為沒有進程上下文, 沒有和任何特定進程相關聯(lián)的到用戶空間的途徑.

• 這個 current 指針在原子態(tài)沒有意義, 并且不能使用因為相關的代碼沒有和已被中斷的進程的聯(lián)系.

• 不能進行睡眠或者調度. 原子代碼不能調用 schedule 或者某種 wait_event, 也不能調用任何其他可能睡眠的函數(shù). 例如, 調用 kmalloc(..., GFP_KERNEL) 是違犯規(guī)則的. 旗標也必須不能使用因為它們可能睡眠.

內核代碼能夠告知是否它在中斷上下文中運行, 通過調用函數(shù) in_interrupt(), 它不要參數(shù)并且如果處理器當前在中斷上下文運行就返回非零, 要么硬件中斷要么軟件中斷.

一個和 in_interrupt() 相關的函數(shù)是 in_atomic(). 它的返回值是非零無論何時調度被禁止; 這包含硬件和軟件中斷上下文以及任何持有自旋鎖的時候. 在后一種情況, current 可能是有效的, 但是存取用戶空間被禁止, 因為它能導致調度發(fā)生. 無論何時你使用 in_interrupt(), 你應當真正考慮是否 in_atomic 是你實際想要的. 2 個函數(shù)都在 <asm/hardirq.h> 中聲明.

內核定時器的另一個重要特性是一個任務可以注冊它本身在后面時間重新運行. 這是可能的, 因為每個 timer_list 結構在運行前從激活的定時器鏈表中去連接, 并且因此能夠馬上在其他地方被重新連接. 盡管反復重新調度相同的任務可能表現(xiàn)為一個無意義的操作, 有時它是有用的. 例如, 它可用作實現(xiàn)對設備的查詢.

也值得了解在一個 SMP 系統(tǒng), 定時器函數(shù)被注冊時相同的 CPU 來執(zhí)行, 為在任何可能的時候獲得更好的緩存局部特性. 因此, 一個重新注冊它自己的定時器一直運行在同一個 CPU.

不應當被忘記的定時器的一個重要特性是, 它們是一個潛在的競爭條件的源, 即便在一個單處理器系統(tǒng). 這是它們與其他代碼異步運行的一個直接結果. 因此, 任何被定時器函數(shù)存取的數(shù)據(jù)結構應當保護避免并發(fā)存取, 要么通過原子類型( 在第 1 章的"原子變量"一節(jié)) 要么使用自旋鎖( 在第 9 章討論 ).

7.4.1.?定時器 API

內核提供給驅動許多函數(shù)來聲明, 注冊, 以及去除內核定時器. 下列的引用展示了基本的代碼塊:

#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);

這個數(shù)據(jù)結構包含比曾展示過的更多的字段, 但是這 3 個是打算從定時器代碼自身以外被存取的. 這個 expires 字段表示定時器期望運行的 jiffies 值; 在那個時間, 這個 function 函數(shù)被調用使用 data 作為一個參數(shù). 如果你需要在參數(shù)中傳遞多項, 你可以捆綁它們作為一個單個數(shù)據(jù)結構并且傳遞一個轉換為 unsiged long 的指針, 在所有支持的體系上的一個安全做法并且在內存管理中相當普遍( 如同 15 章中討論的 ). expires 值不是一個 jiffies_64 項因為定時器不被期望在將來很久到時, 并且 64-位操作在 32-位平臺上慢.

這個結構必須在使用前初始化. 這個步驟保證所有的成員被正確建立, 包括那些對調用者不透明的. 初始化可以通過調用 init_timer 或者 安排 TIMER_INITIALIZER 給一個靜態(tài)結構, 根據(jù)你的需要. 在初始化后, 你可以改變 3 個公共成員在調用 add_timer 前. 為在到時前禁止一個已注冊的定時器, 調用 del_timer.

jit 模塊包括一個例子文件, /proc/jitimer ( 為 "just in timer"), 它返回一個頭文件行以及 6 個數(shù)據(jù)行. 這些數(shù)據(jù)行表示當前代碼運行的環(huán)境; 第一個由讀文件操作產(chǎn)生并且其他的由定時器. 下列的輸出在編譯內核時被記錄:

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 的數(shù)目( 在單處理器系統(tǒng)上一直為 0).

如果你讀 /proc/jitimer 當系統(tǒng)無負載時, 你會發(fā)現(xiàn)定時器的上下文是進程 0, 空閑任務, 它被稱為"對換進程"只要由于歷史原因.

用來產(chǎn)生 /proc/jitimer 數(shù)據(jù)的定時器是缺省每 10 jiffies 運行一次, 但是你可以在加載模塊時改變這個值通過設置 tdelay ( timer delay ) 參數(shù).

下面的代碼引用展示了 jit 關于 jitimer 定時器的部分. 當一個進程試圖讀取我們的文件, 我們建立這個定時器如下:

unsigned long j = jiffies;
/* fill the data for our timer function */
data->prevjiffies = j;

data->buf = buf2;
data->loops = JIT_ASYNC_LOOPS;

/* register the timer */
data->timer.data = (unsigned long)data;
data->timer.function = jit_timer_fn;
data->timer.expires = j + tdelay; /* parameter */
add_timer(&data->timer);

/* wait for the buffer to fill */
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 包括幾個比上面介紹的那些更多的功能. 下面的集合是完整的核提供的函數(shù)列表:

int mod_timer(struct timer_list *timer, unsigned long expires);
更新一個定時器的超時時間, 使用一個超時定時器的一個普通的任務(再一次, 關馬達軟驅定時器是一個典型例子). mod_timer 也可被調用于非激活定時器, 那里你正常地使用 add_timer.

int del_timer_sync(struct timer_list *timer);
如同 del_timer 一樣工作, 但是還保證當它返回時, 定時器函數(shù)不在任何 CPU 上運行. del_timer_sync 用來避免競爭情況在 SMP 系統(tǒng)上, 并且在 UP 內核中和 del_timer 相同. 這個函數(shù)應當在大部分情況下比 del_timer 更首先使用. 這個函數(shù)可能睡眠如果它被從非原子上下文調用, 但是在其他情況下會忙等待. 要十分小心調用 del_timer_sync 當持有鎖時; 如果這個定時器函數(shù)試圖獲得同一個鎖, 系統(tǒng)會死鎖. 如果定時器函數(shù)重新注冊自己, 調用者必須首先確保這個重新注冊不會發(fā)生; 這常常同設置一個" 關閉 "標志來實現(xiàn), 這個標志被定時器函數(shù)檢查.

int timer_pending(const struct timer_list * timer);
返回真或假來指示是否定時器當前被調度來運行, 通過調用結構的其中一個不透明的成員.

7.4.2.?內核定時器的實現(xiàn)

為了使用它們, 盡管你不會需要知道內核定時器如何實現(xiàn), 這個實現(xiàn)是有趣的, 并且值得看一下它們的內部.

定時器的實現(xiàn)被設計來符合下列要求和假設:

• 定時器管理必須盡可能簡化.

• 設計應當隨著激活的定時器數(shù)目上升而很好地適應.

• 大部分定時器在幾秒或最多幾分鐘內到時, 而帶有長延時的定時器是相當少見.

• 一個定時器應當在注冊它的同一個 CPU 上運行.

由內核開發(fā)者想出的解決方法是基于一個每-CPU 數(shù)據(jù)結構. 這個 timer_list 結構包括一個指針指向這個的數(shù)據(jù)結構在它的 base 成員. 如果 base 是 NULL, 這個定時器沒有被調用運行; 否則, 這個指針告知哪個數(shù)據(jù)結構(并且, 因此, 哪個 CPU )運行它. 每-CPU 數(shù)據(jù)項在第 8 章的"每-CPU變量"一節(jié)中描述.

無論何時內核代碼注冊一個定時器( 通過 add_timer 或者 mod_timer), 操作最終由 internal_add_timer 進行( 在kernel/timer.c), 它依次添加新定時器到一個雙向定時器鏈表在一個關聯(lián)到當前 CPU 的"層疊表" 中.

這個層疊表象這樣工作: 如果定時器在下一個 0 到 255 jiffies 內到時, 它被添加到專供短時定時器 256 列表中的一個上, 使用 expires 成員的最低有效位. 如果它在將來更久時間到時( 但是在 16,384 jiffies 之前 ), 它被添加到基于 expires 成員的 9 - 14 位的 64 個列表中一個. 對于更長的定時器, 同樣的技巧用在 15 - 20 位, 21 - 26 位, 和 27 - 31 位. 帶有一個指向將來還長時間的 expires 成員的定時器( 一些只可能發(fā)生在 64-位 平臺上的事情 ) 被使用一個延時值 0xffffffff 進行哈希處理, 并且?guī)в性谶^去到時的定時器被調度來在下一個時鐘嘀噠運行. (一個已經(jīng)到時的定時器模擬有時在高負載情況下被注冊, 特別的是如果你運行一個可搶占內核).

當觸發(fā) __run_timers, 它為當前定時器嘀噠執(zhí)行所有掛起的定時器. 如果 jiffies 當前是 256 的倍數(shù), 這個函數(shù)還重新哈希處理一個下一級別的定時器列表到 256 短期列表, 可能地層疊一個或多個別的級別, 根據(jù)jiffies 的位表示.

這個方法, 雖然第一眼看去相當復雜, 在幾個和大量定時器的時候都工作得很好. 用來管理每個激活定時器的時間獨立于已經(jīng)注冊的定時器數(shù)目并且限制在幾個對于它的 expires 成員的二進制表示的邏輯操作上. 關聯(lián)到這個實現(xiàn)的唯一的開銷是給 512 鏈表頭的內存( 256 短期鏈表和 4 組 64 更長時間的列表) -- 即 4 KB 的容量.

函數(shù) __run_timers, 如同 /proc/jitimer 所示, 在原子上下文運行. 除了我們已經(jīng)描述過的限制, 這個帶來一個有趣的特性: 定時器剛好在合適的時間到時, 甚至你沒有運行一個可搶占內核, 并且 CPU 在內核空間忙. 你可以見到發(fā)生了什么當你在后臺讀 /proc/jitbusy 時以及在前臺 /proc/jitimer. 盡管系統(tǒng)看來牢固地被鎖住被這個忙等待系統(tǒng)調用, 內核定時器照樣工作地不錯.

但是, 記住, 一個內核定時器還遠未完善, 因為它受累于 jitter 和 其他由硬件中斷引起怪物, 還有其他定時器和其他異步任務. 雖然一個關聯(lián)到簡單數(shù)字 I/O 的定時器對于一個如同運行一個步進馬達或者其他業(yè)余電子設備等簡單任務是足夠的, 它常常是不合適在工業(yè)環(huán)境中的生產(chǎn)系統(tǒng). 對于這樣的任務, 你將最可能需要依賴一個實時內核擴展.