linux新核心的時鐘機制代碼讀後感

如果說cfs是linux的一個很有創意的機制的話，那麼linux中另一個創意就是nohz，我在前面已 經寫了好幾篇關于nohz的文章了，是以本文就不再闡述代碼細節了，linux的創意在于設計而不在代碼，代碼主要解決的問題是實用性，就像gcc一樣， 就是一個編譯器，應用編譯原理設計而出，它内部卻充實着編譯原理之外的巧妙。有血有肉才活得精彩，如果說nohz之前的linux核心是骨架的話，那麼從 nohz之後，linux開始了精彩，之後幾乎瞬時，cfs出現了，然後是cgroup...cgroup正式開始了虛拟容器，從此linux再也不用被 unix老大們看作是小孩子了，nohz标志着linux開始成熟起來。nohz為何這麼重要呢？因為它直接關系到了性能，直接聯系着系統的心跳，在之 前，系統總是被動的接受時鐘中斷，然後運作中斷處理程式最終可能導緻排程的發生，如果實在沒有任務可以運作，那麼就執行idle，這也許也算一種創意，可 是時鐘中斷還是會周期性的打破idle，然後查詢有沒有需要做的事情，如果沒有繼續idle，這種方式沒有什麼問題，可是我們總是希望系統可以主動的做些 事情，比如不是被動的接受中斷而是主動的設定什麼時候中斷，是以必須将系統時鐘發生中斷這件事進行向上抽象，于是相應的clocksource和 clock_event_device，這兩個結構體就是時鐘以及時鐘行為的抽象，clocksource代表了一個時鐘源，一般都會有一個計數器，其中 的read回調函數就是負責讀出其計數器的值，可是我們為何找不到write或者set之類的回調函數呢？這些回調函數其實不應該在 closksource中，而應該在clock_event_device中，實際上，clockevent隻是一個鐘，你可以類比我們用的鐘 表，clocksource就是一個鐘表，我們需要一個鐘表就是需要讀出它的指針的值進而知道現在幾點，就是這些，是以鐘表都會有顯示盤用于讀數，至于鐘 表怎麼運作，那就是鐘表内部的機械原理了，記住，鐘表就是用來讀數的，另外我們為了害怕誤事而需要鬧鈴，需要的是鬧鈴在一個時間段之後把我們喚醒，這是個 事情，而這個事情不一定非要有鐘表，當然鐘表的讀數會為我們提供有用的參考值，這樣的話鐘表和鬧鈴就解耦合了，再重申一遍，不要因為有鬧鐘的存在就說鐘表 都會響鈴或者說鬧鈴都有鐘表，它們其實是兩個東西，鐘表為你展示某些事情，而鬧鈴需要你的設定，設想一個場景，你手邊有一個沒有鬧鈴的鐘表，還有一個沒有 鐘表的鬧鈴，這個鬧鈴隻能設定絕對時間，然後到期振鈴，你現在不知道幾點，可是你要睡覺并且得到通知必須在四個小時後去參加一個聚會，那麼你現在要做什 麼？你肯定要看看你的鐘表，然後設定你的鬧鐘。 

以上的例子中，鐘表就是clocksource，而鬧鐘就是clock_event_device，前者提供了一個訓示盤，後者封裝了鬧鈴到期以後的行為 以及設定鬧鈴的把手，就好像你的鬧鈴都有旋鈕一樣。既然作業系統的行為是時鐘中斷驅動的，那麼它很符合我剛才例子中的那個邏輯，即使不用在核心中抽象出 clocksource和clock_event_device這些概念，隻要能做到定時“振鈴”，然後去執行時鐘中斷就可以了，2.6.18之前的核心 中在沒有抽象出“鐘表”和“鬧鈴”的情況下實作了上述的邏輯，可是這種方式有一個預設的前提就是核心一直有事可做，軟體是硬體的奴隸，不得不在硬體的預設 前提下每隔一個時間段就被中斷一次，而硬體隻管定時中斷而不管到底是否真正有事可做，理想的實作應該是将定時的任務交給核心自己，就好比我希望定一個鬧鈴 到一定時間後叫醒我，我希望我自己定這個鬧鈴而不是希望到時間我正在熟睡而被不知情的叫醒，2.6.18以前的核心中，根本就沒有簡單的“定鬧鈴”的把 手，是以不得不忍受硬體的有事無事的定時中斷。clocksource和clock_event_device被抽象出來以 後，clock_event_device中有了定鬧鈴的把手，一切就醒目多了，實際上clocksource和clock_event_device被 抽象出來并不是為了nohz，而是為了将時鐘相關的代碼從平台相關的代碼中分離出來，以便于獨立修改統一管理，否則需要維護很多平台的不同的時鐘處理代 碼，而這些代碼的邏輯大緻相同，随後的2.6.22以後，nohz才出現，nohz其實就是托了抽象出來的clocksource和 clock_event_device的福，因為nohz直接需要設定下一次的中斷時間而不是使用系統無條件的預設的HZ中斷。 clock_event_device中的set_next_event就是定鬧鈴的把手，而event_handler則是可以讓你自己定義鬧鈴到期後 的事件，就好比手機定鬧鈴時可以選到期後播放的音樂一樣可以自定義事件處理回調函數。 

 本文轉自 dog250 51CTO部落格，原文連結:http://blog.51cto.com/dog250/1273491