“拼湊內(nèi)核”這套連載做到第三章第三節(jié)前兩回我們已經(jīng)把中斷控制器、時鐘芯片驅(qū)動和任務(wù)切換勉強跑通代碼能在一個模擬環(huán)境下“活”起來。這一節(jié)要聊的軟件定時器正好是整個內(nèi)核里非常討巧的一塊基礎(chǔ)設(shè)施它不直接碰硬件卻依賴時鐘中斷這個“心跳”來驅(qū)動自己。你可能會說不就是一個到了時間就執(zhí)行回調(diào)的機制嗎實際寫起來遠沒那么簡單從數(shù)據(jù)結(jié)構(gòu)怎么設(shè)計、時間怎么換算到高并發(fā)下怎么安全地刪一個定時器坑一個接一個。這篇內(nèi)容適合兩類讀者一類是正在跟做操作系統(tǒng)實驗、想把手寫內(nèi)核里程碑補全的學(xué)生另一類是剛接觸內(nèi)核驅(qū)動開發(fā)、想弄明白timer_list和hrtimer到底怎么用的工程師。我會從“為什么需要軟件定時器”講起一路說到時間輪算法、實際驅(qū)動里的用法和調(diào)試經(jīng)驗盡量把教材里一筆帶過的地方展開講透。1. 軟件定時器是什么為什么內(nèi)核離不開它1.1 從硬件定時器到軟件定時器硬件定時器是芯片上一組獨立的計數(shù)器電路比如常見的可編程間隔定時器它由外部晶振提供時鐘源計數(shù)到設(shè)定值后觸發(fā)中斷。問題在于一塊板子上的硬件定時器通道非常有限而內(nèi)核里需要“延遲執(zhí)行”“超時判斷”“周期性任務(wù)”的地方數(shù)不勝數(shù)網(wǎng)絡(luò)協(xié)議棧要重傳超時、塊設(shè)備層要處理請求超時、內(nèi)核線程要做周期調(diào)度統(tǒng)計?？坑布〞r器一個一個去滿足完全不現(xiàn)實。所以內(nèi)核把硬件定時器當(dāng)作一個“節(jié)拍發(fā)生器”讓它以固定頻率產(chǎn)生時鐘中斷每次中斷到來時軟件定時器模塊就被喚起一次檢查哪些定時器到期然后執(zhí)行對應(yīng)的回調(diào)函數(shù)。這樣一個或幾個硬件通道就能支撐無數(shù)個軟件定時器同時運行。軟件定時器的本質(zhì)就是把“時間維度上的事件調(diào)度”從硬件遷移到軟件層面。它犧牲了一點精度換來的是數(shù)量上的幾乎無上限。編寫驅(qū)動時你申請一個軟件定時器只是在內(nèi)存里填了個結(jié)構(gòu)體注冊到內(nèi)核的定時器鏈表里不再占用任何硬件資源。這東西在實戰(zhàn)里的出場頻率極高凡是驅(qū)動里需要“等一會兒再做事”的邏輯基本都要靠它。1.2 兩個必需的基礎(chǔ)概念時鐘節(jié)拍與 jiffies理解軟件定時器繞不開兩個底層概念一個是時鐘節(jié)拍tick一個是jiffies。系統(tǒng)開機后硬件定時器被編程為每1/HZ秒產(chǎn)生一次中斷這個時間單位被稱為一個 tick。HZ是一個編譯期常量常見取值是 100、250、1000含義是每秒產(chǎn)生多少個時鐘中斷。如果HZ250那么每個 tick 就是 4 毫秒軟件定時器的精度上限就鎖死在 4 毫秒——你說我想定時 1 毫秒老式的低精度定時器是做不到的這是你先要接受的一個硬約束。jiffies是內(nèi)核里的全局“心跳計數(shù)器”每次時鐘中斷它自增 1。它從開機開始累積類型是unsigned long volatile在 32 位系統(tǒng)上大約 497 天后會回繞一次64 位系統(tǒng)上這個概念基本可以忽略。所有軟件定時器的到期時間都以jiffies為單位表示。一個定時器的生命周期是這樣的初始化時填好回調(diào)函數(shù)和參數(shù)設(shè)置一個到期時間差比如“10 個 jiffies 之后”然后掛到內(nèi)核的管理結(jié)構(gòu)中。之后每來一次時鐘中斷內(nèi)核就把jiffies加 1并檢查有沒有到期項。這種設(shè)計把硬件只需要負責(zé)“周期性發(fā)中斷”這一件事其余全部邏輯都收攏到通用的軟件框架里。2. 定時器對象與常用 API一切從數(shù)據(jù)結(jié)構(gòu)開始2.1 struct timer_list 是怎么設(shè)計的經(jīng)典低精度定時器的結(jié)構(gòu)體定義不同內(nèi)核版本略有差異但核心成員一直是那幾項。我以比較普及的內(nèi)核版本為參考struct timer_list { struct hlist_node entry; // 掛入時間輪散列表的節(jié)點 unsigned long expires; // 到期時刻單位jiffies void (*function)(struct timer_list *); // 回調(diào)函數(shù) u32 flags; // 標(biāo)志位 } __randomize_layout;entry用來把定時器節(jié)點掛到內(nèi)核的時間輪桶里這個成員在用戶視角不需要碰。expires是絕對到期時間注意是“絕對值”而不是“還要等多久”。如果現(xiàn)在jiffies是 10000你想等 20 個 tick就要填 10020而不是填 20。這個細節(jié)新手經(jīng)常搞反一旦填了相對值定時器要么立即觸發(fā)要么等到系統(tǒng)運行很久很久之后才輪到它看起來就是“定時器完全不可用”。function是回調(diào)函數(shù)指針?biāo)娜雲(yún)⑹莝truct timer_list *也就是說回調(diào)函數(shù)能拿到定時器結(jié)構(gòu)體本身。經(jīng)典教材里老版本內(nèi)核經(jīng)常寫void my_callback(unsigned long data)這是 2.6 時代的老接口?，F(xiàn)在統(tǒng)一改成傳入struct timer_list *好處很明顯回調(diào)里可以直接用container_of通過定時器結(jié)構(gòu)找到宿主數(shù)據(jù)結(jié)構(gòu)不需要依賴一個裸的unsigned long參數(shù)。比如你在一個設(shè)備結(jié)構(gòu)體里內(nèi)嵌了定時器回調(diào)函數(shù)里就能通過container_of找回整個設(shè)備結(jié)構(gòu)體。flags字段在正常驅(qū)動開發(fā)時通常直接傳 0。它內(nèi)部可能攜帶一些與 CPU 親和性相關(guān)的標(biāo)記但這是內(nèi)核框架自己用的驅(qū)動層一般不需要主動設(shè)置。2.2 初始化的正確姿勢timer_setup初始化接口現(xiàn)在統(tǒng)一使用timer_setup它把setup_timer那套老 API 淘汰了。一個典型的初始化是這樣的static struct timer_list my_timer; static void my_timer_handler(struct timer_list *t) { // 定時器到期的處理邏輯 } static int __init xxx_init(void) { timer_setup(my_timer, my_timer_handler, 0); // 此時定時器還沒掛到時間輪上只是完成了對象初始化 return 0; }timer_setup會把回調(diào)函數(shù)指針填好把節(jié)點的鏈表指針清空標(biāo)志位置好。這一步只做“對象初始化”不參與調(diào)度。很多不熟悉內(nèi)核框架的人以為初始化完就開始計時了其實還差兩步設(shè)置到期時間把定時器真正掛載到時間輪桶中。獨立設(shè)置到期時間可以用timer-expires jiffies x但更推薦用輔助函數(shù)mod_timer(my_timer, jiffies msecs_to_jiffies(100));mod_timer是“修改到期時間并掛載”的復(fù)合操作。如果定時器已經(jīng)在時間輪里它會把舊的桶節(jié)點摘下來按新到期時間重新插入如果定時器還沒掛載它就直接以新到期時間掛進去。這個接口內(nèi)部會做必要的同步保護是驅(qū)動開發(fā)里最常用的一個入口。還有一對容易混淆的刪除接口。del_timer只是把節(jié)點從時間輪里摘下來不關(guān)心是否已注冊也不關(guān)心是否正在其他 CPU 上執(zhí)行回調(diào)流程。del_timer_sync額外保證當(dāng)函數(shù)返回時該定時器的回調(diào)函數(shù)一定沒有在其他 CPU 上運行或者已經(jīng)運行完畢。在驅(qū)動卸載路徑上最穩(wěn)妥的選擇是del_timer_sync。2.3 改期mod_timer 的語義坑mod_timer的語義比很多入門文檔寫的更強。除了“改到期時間”它實際上等價于“若已激活則先刪除、再按新時間激活”。這意味著一個已激活的定時器可以反復(fù)用mod_timer調(diào)整時間實現(xiàn)“滾動定時器”也就是周期性任務(wù)。但這里有第一個值得警惕的坑mod_timer返回 0 表示定時器之前是未激活的返回 1 表示它之前已經(jīng)激活并被重新調(diào)度了。有些驅(qū)動代碼只關(guān)心“定時器有沒有被激活過”就可以利用這個返回值做狀態(tài)判斷。不過我要提醒你別在工作量很大的回調(diào)函數(shù)里反復(fù)高頻調(diào)用mod_timer那會引入不必要的鎖競爭和處理器間干擾。批量執(zhí)行周期任務(wù)時更推薦用hrtimer或者內(nèi)核工作隊列配合延時函數(shù)。3. 時間換算的藝術(shù)從用戶態(tài)的毫秒到內(nèi)核的 jiffies3.1 常用換算函數(shù)清單應(yīng)用層程序員用毫秒、微秒內(nèi)核里的人卻活在jiffies里。兩種時間單位之間必須顯式換算不能想當(dāng)然地直接賦值。Linux 內(nèi)核提供了一組語義清晰的輔助函數(shù)msecs_to_jiffies(m)毫秒轉(zhuǎn) jiffies向上取整usecs_to_jiffies(u)微秒轉(zhuǎn) jiffies向上取整timespec_to_jiffies(ts)結(jié)構(gòu)體時間轉(zhuǎn) jiffiesjiffies_to_msecs(j)反向換算用于把內(nèi)核時間輸出給用戶態(tài)為什么要“向上取整”因為內(nèi)核定時器的到期檢查粒度是 tick。當(dāng)HZ1000時每個 tick 是 1 毫秒user 傳一個 1.5 毫秒的延時如果不向上取整直接按照 1 毫秒算實際延時就會比請求時間短。向上取整能保證“只晚不早”這在超時類業(yè)務(wù)里是行規(guī)——寧可晚一點喚醒不能早一點誤判超時。來看一個實際換算unsigned long delay msecs_to_jiffies(250); mod_timer(my_timer, jiffies delay);當(dāng)HZ100時250 毫秒等于 25 個 jiffies取整后沒有任何誤差。當(dāng)HZ1000時250 毫秒等于 250 個 jiffies。但如果傳入 255 毫秒且HZ100因為一個 tick 是 10 毫秒25.5 必須向上取整到 26 個 tick實際到期時間就變成了 260 毫秒誤差 5 毫秒。注意在模塊代碼中做了msecs_to_jiffies之后不要再試圖把結(jié)果轉(zhuǎn)換成毫秒傳回用戶態(tài)。內(nèi)核內(nèi)部的時間處理必須保持在 native 單位里進行反復(fù)橫跳只會引入無謂的精度損失。3.2 HZ 的取值是個權(quán)衡不是越大越好有人覺得把HZ配成 1000定時器精度變成 1 毫秒豈不是更好事情沒有這么簡單。HZ越大每個 tick 間隔越短做一次進程調(diào)度、檢查定時器、更新系統(tǒng)統(tǒng)計的頻率就越高。這些工作全部疊加在中斷上下文里會吃掉不少 CPU 周期。桌面內(nèi)核傾向于 250 或 1000 讓交互更順滑服務(wù)器內(nèi)核反而傾向 100因為大批量計算任務(wù)根本不在乎這幾毫秒的定時粒度省下中斷開銷才是實打?qū)嵉氖找?。低精度軟件定時器的精度上限就是/HZ秒。有些課程實驗把HZ設(shè)成 10那定時器誤差高達 100 毫秒做簡單的 LED 閃爍沒問題做網(wǎng)絡(luò)重傳計時就完全不可用。所以你寫代碼時凡是精度敏感的場合要對HZ足夠敏感凡是要求微秒級定時的場合就該扭頭去看hrtimer而不是指望提高HZ來硬扛。3.3 和 real time 的差異定時器到點了不代表現(xiàn)在是那個時刻軟件定時器的到期事件發(fā)生在時鐘中斷上下文里它表示的是“系統(tǒng)運行了足夠多的 tick”而不是“現(xiàn)實世界過去了準(zhǔn)確的時間”。系統(tǒng)休眠、內(nèi)核被搶占、中斷長時間關(guān)閉都會讓定時器觸發(fā)晚點。如果你在用戶態(tài)通過gettimeofday去測量定時器到點的真實時刻會發(fā)現(xiàn)它可能偏差幾毫秒甚至更久。這在實時性要求到“必須準(zhǔn)點”的應(yīng)用里是不能接受的。結(jié)論很簡單低精度定時器適合做“相對延時、超時判斷、輪詢節(jié)流”不適合做“硬實時調(diào)度”。要硬實時用hrtimer它基于硬件時鐘提供的精確時間線與jiffies解耦。4. 定時器核心機制從樸素鏈表到多級時間輪4.1 樸素鏈表實現(xiàn)為什么不行如果讓你設(shè)計一個最簡單的定時器框架腦子里第一反應(yīng)肯定是維護一個全局有序鏈表每個節(jié)點記錄到期時間。時鐘中斷來了從鏈表頭開始檢查凡是expires jiffies的節(jié)點都取出來執(zhí)行然后把它們從鏈表里摘除。插入時按到期時間排序保持鏈表有序。這個方案的瓶頸非常明顯。插入一個定時器的時間復(fù)雜度是 O(n)因為要沿著鏈表找到合適的位置最壞情況下系統(tǒng)的定器數(shù)量如果有數(shù)千個每次插入都是一次大規(guī)模的線性掃描。海量定時器情況下中斷處理函數(shù)里做這種高成本操作是不可接受的。你想想網(wǎng)絡(luò)棧里每個連接可能同時掛著若干超時定時器高并發(fā)服務(wù)器上定時器數(shù)量輕松上萬線性掃描幾萬個節(jié)點中斷延遲會被拖垮。4.2 多級時間輪的核心思想內(nèi)核采用的多級時間輪本質(zhì)上是“以空間換時間”的典型代表也是各種高性能定時器方案的基礎(chǔ)思想。想象鐘表上的表盤秒針走一圈 60 格每走一格是 1 秒分針 60 格時針 12 格。秒針走完一圈分針動一格分針走完一圈時針動一格。多級時間輪完全復(fù)刻了這種“進制”思想。具體到內(nèi)核時間輪有 5 個級別每個級別是一個桶數(shù)組。第一級桶數(shù)量較多每個桶代表一個 tick后面每個級別的桶數(shù)量變少但每個桶代表的 tick 數(shù)成倍放大。當(dāng)?shù)谝患壍哪硞€桶輪轉(zhuǎn)到位時如果發(fā)現(xiàn)里面有定時器就把他們從第一級的桶取出來重新按剩余時間散列到更精確的級別里去。這個動作叫“級聯(lián)”。在中斷處理里內(nèi)核只需要看當(dāng)前 tick 對應(yīng)第一級的哪個桶把那個桶里的定時器全部取出來執(zhí)行即可。每過固定數(shù)量的 tick才需要把下一級的桶展開、重新散列所以平均下來每個 tick 的開銷非常小插入和刪除還是 O(1) 時間。它跟有序鏈表最大的差別在于不排序只散列到固定的時間區(qū)間里。4.3 索引計算一個簡化的時間輪推導(dǎo)我用一個簡化版本來演示索引計算邏輯幫助你建立直覺。假設(shè)第一級桶數(shù)組有 8 個桶時間范圍是一個 8-tick 周期?，F(xiàn)在jiffies當(dāng)前值是base某個定時器到期值是expires。它在第一級桶里的索引可以直接用index (expires 7);因為底層是 8 個桶取低 3 位即可。問題在于當(dāng)?shù)谝患壿嗈D(zhuǎn)多次以后只靠低 3 位就無法區(qū)分這個到期時間落在哪一個輪次里。所以需要二級輪子。兩級時間輪做法是第一級 8 個桶每格 1 個 tick第二級也是 8 個桶但每格代表“第一級完整輪轉(zhuǎn)一圈”的長度。第二級一個格子里掛的定時器到期時間離jiffies的距離會是“幾個完整輪”加“桶內(nèi)偏移”。計算第二級索引時需要先算出時間差再除以第一級周期得到“圈數(shù)”然后對第二級取模。處理流程是這樣的每次 tick檢查第一級對應(yīng)的桶執(zhí)行桶內(nèi)所有到期定時器。當(dāng)?shù)谝患夀D(zhuǎn)完一整圈觸發(fā)一次提升把第二級當(dāng)前桶里的定時器全部取出。對每個取出的定時器按新的剩余時間重新放回第一級的某個桶或者放到更高一級。這就是級聯(lián)定時器的基本運作。真實內(nèi)核里的時間輪比這個演示復(fù)雜但底層的“區(qū)間劃分、級聯(lián)、O(1) 插入刪除”核心一模一樣。在實現(xiàn)自己的小內(nèi)核時你完全可以先用這個簡化版本先把功能跑通再去考慮匹配真實內(nèi)核的實現(xiàn)細節(jié)。重要提醒寫內(nèi)核代碼時別自己去實現(xiàn)一套多級時間輪替代內(nèi)核自帶定時器除非你是在課程作業(yè)里自己拼一個微型內(nèi)核。真實內(nèi)核的時間輪已經(jīng)處理了 SMP 并發(fā)、回調(diào)上下文、延遲遷移等各種邊界自己造輪子很難在正確性上勝過它。5. 實操在一個內(nèi)核模塊里用好軟件定時器5.1 場景設(shè)計與完整示例現(xiàn)在我們把知識落到代碼上。場景寫一個非常簡單的內(nèi)核模塊它提供一個 proc 節(jié)點用戶往節(jié)點寫一個毫秒數(shù)值模塊就在指定時長后打印一條日志并自動把時間重置為下一個周期實現(xiàn)周期性打印。#include linux/module.h #include linux/kernel.h #include linux/timer.h #include linux/jiffies.h #include linux/proc_fs.h #include linux/uaccess.h static struct timer_list demo_timer; static unsigned long interval_jiffies HZ; /* 默認(rèn) 1 秒 */ static void demo_timer_callback(struct timer_list *t) { pr_info(demo timer fired at %lu\n, jiffies); /* 周期持續(xù)運行把到期時間改到當(dāng)前時間再加一個間隔 */ mod_timer(demo_timer, jiffies interval_jiffies); } static ssize_t demo_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos) { char kbuf[32]; unsigned int msecs 0; if (count sizeof(kbuf)) return -EINVAL; if (copy_from_user(kbuf, buf, count)) return -EFAULT; kbuf[count] \0; if (kstrtouint(kbuf, 10, msecs)) return -EINVAL; if (msecs 0) interval_jiffies HZ; else interval_jiffies msecs_to_jiffies(msecs); mod_timer(demo_timer, jiffies interval_jiffies); pr_info(timer interval updated to %u ms\n, msecs); return count; } static const struct proc_ops demo_proc_ops { .proc_write demo_write, }; static int __init demo_init(void) { timer_setup(demo_timer, demo_timer_callback, 0); mod_timer(demo_timer, jiffies interval_jiffies); proc_create(demo_timer, 0666, NULL, demo_proc_ops); pr_info(demo timer module loaded\n); return 0; } static void __exit demo_exit(void) { remove_proc_entry(demo_timer, NULL); del_timer_sync(demo_timer); pr_info(demo timer module unloaded\n); } module_init(demo_init); module_exit(demo_exit); MODULE_LICENSE(GPL);這個模塊的設(shè)計有幾個值得琢磨的點。第一回調(diào)函數(shù)里把mod_timer放在最后一行而不是放在回調(diào)一開始這樣能避免一種競爭如果定時器剛被觸發(fā)此刻還沒有重新排隊用戶在 proc 寫操作里改時間邊界的順序就變得可控。先重新排期再打印日志是更好的做法但為了代碼簡潔放在pr_info之后也問題不大——只要你不在這兩者之間做狀態(tài)清理。第二del_timer_sync是卸載時最關(guān)鍵的一行。模塊退出函數(shù)里先刪除 proc 節(jié)點防止新用戶操作進來再同步刪除定時器保證回調(diào)函數(shù)已經(jīng)不在任何處理器上運行之后才能放心釋放模塊申請的資源。順序不能反如果先刪定時器再刪 proc 節(jié)點中間窗口期用戶還是可能改定時器的到期時間卸載路徑上就多了一個需要同步的變量。第三用戶傳入 0 毫秒時的處理。把它當(dāng)成重置為默認(rèn)值這里使用 0 作為非法值是刻意設(shè)計避免msecs_to_jiffies(0)直接生成 0 個 jiffies 導(dǎo)致定時器立刻觸發(fā)讓系統(tǒng)陷入空轉(zhuǎn)。5.2 回調(diào)函數(shù)里什么事情絕對不能做如果說定時器 API 是形式那回調(diào)函數(shù)的約束才是靈魂。軟件定時器的回調(diào)運行在軟中斷上下文準(zhǔn)確說是TIMER_SOFTIRQ這種軟中斷環(huán)境里不是進程上下文。這里有幾條高壓線不能調(diào)用sleep或任何可能睡眠的函數(shù)比如msleep、wait_event、mutex_lock。睡眠會導(dǎo)致軟中斷卡死進而連累整個系統(tǒng)的定時器分發(fā)。不能調(diào)用kmalloc并帶有GFP_KERNEL標(biāo)志因為分配內(nèi)存可能需要阻塞來回收頁面。這時候要用GFP_ATOMIC但也要盡量少用。不能直接操作用戶態(tài)內(nèi)存比如通過指針訪問用戶空間地址。因為此時沒有合法的進程地址空間上下文。不能長時間自旋忙等因為軟中斷期間本地中斷處理也受約束長時間忙等會讓其他中斷延遲劇增。如果回調(diào)里確實需要做耗時操作標(biāo)準(zhǔn)做法是立刻把一個工作項提交到 Linux 工作隊列定時器回調(diào)只是“叫醒服務(wù)”真正干活的人在進程上下文里運行。用一句話概括定時器回調(diào)是門鈴不是廚師。門鈴響了廚師才從休息室出來開火你不能讓門鈴自己把一整桌菜做出來。static void timer_cb(struct timer_list *t) { /* 只投遞不干活 */ schedule_work(my_work); }5.3 周期定時器三種寫法的取舍實現(xiàn)周期任務(wù)有三種常見寫法我也給新手一個選擇依據(jù)。第一種回調(diào)函數(shù)末尾再調(diào)用mod_timer。優(yōu)點是代碼簡單缺點是如果回調(diào)執(zhí)行時間波動較大周期會跟著漂移因為它總是從“回調(diào)執(zhí)行時刻”重新計算下個到期點。第二種在回調(diào)開頭記錄jiffies末尾用“基準(zhǔn)時刻加上固定間隔”重新設(shè)置到期時間。這能讓周期盡量逼近理想值但要小心如果回調(diào)執(zhí)行時間已經(jīng)超過一個周期就會出現(xiàn)到期時間落在當(dāng)前時間之前的情況mod_timer會對過去時間做什么它會直接通知你馬上到期導(dǎo)致連續(xù)觸發(fā)俗稱“追趕”。第三種用hrtimer的HRTIMER_MODE_REL或HRTIMER_MODE_ABS模式實現(xiàn)高精度周期任務(wù)。雖然更復(fù)雜但能利用硬件時鐘的精確性。比起糾結(jié)低精度定時器的周期漂移直接提升定時器精度往往更省心。我個人寫驅(qū)動時除非目標(biāo)是極簡驗證流程否則周期任務(wù)優(yōu)先考慮用內(nèi)核工作隊列的schedule_delayed_work它自帶延遲調(diào)度語義也更適合跑流程較重的邏輯。6. 常見問題與調(diào)試實錄6.1 癥狀定時器從不觸發(fā)如果加載模塊后日志里一次回調(diào)都沒出現(xiàn)先別急著懷疑 API 用法。多數(shù)情況是下面三個原因之一。第一個原因是到期時間設(shè)置為相對值而不是絕對值。比如寫的是timer.expires 100意思想表達“等 100 個 tick”實際語義卻是“系統(tǒng)運行到 100 個 tick 時就觸發(fā)”。如果系統(tǒng)已經(jīng)跑了幾十萬個 tick這個定時器永遠等不來。解決方式是在打印日志時把jiffies也輸出對比一下當(dāng)前值和到期值。第二個原因是定時器根本沒有被掛到時間輪上。只調(diào)用了timer_setup沒調(diào)add_timer或mod_timer定時器只是初始化了但不在任何桶里。檢查代碼里有沒有真的執(zhí)行掛載操作以及掛載操作是否在 error path 里被跳過。第三個原因是回調(diào)函數(shù)本身出錯導(dǎo)致模塊崩潰但這個癥狀往往不是“從不觸發(fā)”而是觸發(fā)后系統(tǒng)死掉或者模塊 unload 失敗。用 dmesg 抓一下崩潰的棧信息基本都能定位到回調(diào)函數(shù)的哪一行出了問題。我在調(diào)試時習(xí)慣在初始化和回調(diào)入口各打一條帶jiffies的日志這樣能立刻看到時間是否在推進、定時器是否到期、回調(diào)是否入庫。6.2 癥狀模塊卸載時死鎖或者崩潰卸載時遇到死鎖首先要想到del_timer_sync和回調(diào)函數(shù)的鎖順序問題。假設(shè)回調(diào)函數(shù)持有一個鎖 A卸載路徑先拿到同一個鎖 A再去調(diào)用del_timer_sync等回調(diào)結(jié)束這種情況下必定死鎖。因為回調(diào)在等鎖而持鎖方在等回調(diào)結(jié)束。這類死鎖的本質(zhì)是“回調(diào)函數(shù)和卸載路徑共享了同一把鎖”。解決辦法是不要讓卸載路徑持鎖去等待定時器同步結(jié)束可以在釋放鎖之后再做del_timer_sync或者回調(diào)函數(shù)內(nèi)部只用無鎖的原子變量傳遞狀態(tài)。如果卸載時直接崩潰大概率是del_timer_sync之后仍然訪問了回調(diào)函數(shù)可能用到的數(shù)據(jù)。比如某個設(shè)備結(jié)構(gòu)體已經(jīng)被kfree而回調(diào)函數(shù)里還通過container_of把這個結(jié)構(gòu)體取出來用。標(biāo)準(zhǔn)做法是先del_timer_sync保證回調(diào)不再運行再釋放相關(guān)數(shù)據(jù)結(jié)構(gòu)。次序錯了就是“定時器先釋放、回調(diào)后訪問”的懸垂指針災(zāi)難。6.3 癥狀定時器回調(diào)里睡眠導(dǎo)致系統(tǒng)異常新手最容易踩的就是在回調(diào)函數(shù)里調(diào)用msleep(10)。表面看只是一次毫秒級睡眠實際上軟中斷上下文不允許睡眠內(nèi)核會在調(diào)度器入口處打出BUG: scheduling while atomic的警告系統(tǒng)進入不穩(wěn)定狀態(tài)時不時無響應(yīng)。要徹底扭轉(zhuǎn)自己的直覺不是“盡量別在回調(diào)里睡眠”而是“回調(diào)里絕對不許睡眠”。耗時工作全部外包給schedule_work或者queue_work。頻繁觸發(fā)的高頻定時器外包時要注意合并請求避免產(chǎn)生堆積的大量工作項可以考慮使用work_pending之類的判斷來防止重復(fù)提交。附上一份我在教學(xué)時常用的排查速查表可以幫你快速定位問題癥狀可能原因排查方向定時器完全不觸發(fā)expires 填了相對值、沒掛載打印 jiffies 對比檢查 add_timer/mod_timer觸發(fā)時間偏晚HZ 太小、回調(diào)被搶占核對 HZ 配置區(qū)分開軟件定時器與 hrtimer卸載時死鎖鎖順序問題分析卸載路徑與回調(diào)的鎖依賴卸載后崩潰del_timer_sync 之后數(shù)據(jù)被釋放調(diào)整釋放順序先同步刪除定時器再釋放結(jié)構(gòu)體系統(tǒng)警告 scheduling while atomic回調(diào)中睡眠改用工作隊列禁止在回調(diào)里調(diào)用可睡眠函數(shù)定時器被重復(fù)觸發(fā)回調(diào)里 mod_timer 邏輯有誤檢查邊界條件保證至少有一個固定間隔間隔6.4 調(diào)試技巧利用軟中斷上下文信息當(dāng)你在dmesg里看到BUG: scheduling while atomic這類消息時它其實帶著一份調(diào)用棧足以指出睡眠發(fā)生的位置。不要只盯著最后一行BUG標(biāo)題往上翻找__might_sleep調(diào)用之前的函數(shù)鏈找到的是你的定時器回調(diào)被調(diào)用的入口。如果系統(tǒng)只是卡死而不報錯優(yōu)先懷疑鎖的問題而非死循環(huán)。軟中斷里死循環(huán)的現(xiàn)象是所有 CPU 軟中斷被卡住而普通用戶態(tài)任務(wù)可能還能運行。這種區(qū)分方式比無腦打印日志更高效。配合perf采樣可以更精準(zhǔn)定位熱點不過很多人忽略了這里也算一個經(jīng)驗之談。6.5 一個容易忽視的提升點定時器對象的復(fù)用注意定時器對象可以被反復(fù)mod_timer但它不能被同時掛到兩個不同的執(zhí)行路徑上。比如驅(qū)動里如果有兩個線程都想操作同一個定時器各自調(diào)用mod_timer最后的到期時間取決于后調(diào)用的那個。這種競爭在低并發(fā)場景下可能無害但在高并發(fā)驅(qū)動里可能導(dǎo)致一個事件的超時判斷被另一個無關(guān)請求覆蓋。解決辦法很簡單要么保證代碼里只有一個執(zhí)行路徑能修改定時器要么為每個需求創(chuàng)建獨立的定時器實例要么用spinlock保護對定時器的所有操作。我在實際項目中偏好“獨立實例”因為鎖雖簡單但一旦回調(diào)里再操作同一把鎖死鎖風(fēng)險就悄悄爬上來了。獨立實例讓鎖定邊界更清晰是一個工程直覺上的加分選項。收尾之前一句話給你兜底軟件定時器這個模塊說簡單也簡單說難也難。簡單在于它的 API 只有初始化、改期、刪除三個動作復(fù)雜在于它和時鐘中斷、軟中斷、并發(fā)安全、鎖依賴這些問題緊緊抱在一起。在我?guī)н^的新人里能把mod_timer用得順手的人不算少但能同時說清楚“為什么回調(diào)不能睡、為什么卸載要先刪 proc 再刪定時器、為什么 expires 必須填絕對值”的基本都能算對內(nèi)核調(diào)度有點真理解了。最后一件事分享給做實驗的同學(xué)HZ設(shè)置成 100 做演示沒有什么問題但你在文檔里描述定時器精度時記得把CONFIG_HZ的值寫進去否則別人復(fù)現(xiàn)你的實驗換個HZ1000的發(fā)行版內(nèi)核得到的觸發(fā)間隔和你的結(jié)論對不上排查半天發(fā)現(xiàn)是配置差異。我在指導(dǎo)某個學(xué)生項目時踩過這個坑后來所有實驗文檔第一行就固定寫清環(huán)境參數(shù)這類問題再也沒出現(xiàn)過。拼湊內(nèi)核拼到定時器這一站后面的路就順了——畢竟時間能“軟”起來剩下的調(diào)度、超時、協(xié)作就都有地方落腳。