再談Linux內核中的RCU機制
阿新 • • 發佈:2018-03-11
臨界區 內核代碼 lock 釋放 中修改 爆發 完成後 per 等等
RCU讀取側進入臨界區的標誌是調用rcu_read_lock,這個函數的代碼是:
。
接下來關於RCU一個有趣的問題是:何時才能釋放老指針。我見過很多書中對此的回答是:當系統中所有處理器上都發生了一次進程切換。這種程式化的回答常常讓剛接觸RCU機制的讀者感到一頭霧水,為什麽非要等所有處理器上都發生一次進程切換才可以調用回調函數釋放老指針呢?這其實是RCU的設計規則決定的: 所有對老指針的引用只可能發生在rcu_read_lock與rcu_read_unlock所包括的臨界區中,而在這個臨界區中不可能發生進程切換,而一旦出了該臨界區就不應該再有任何形式的對老指針p的引用。很明顯,這個規則要求讀取者在臨界區中不能發生進程切換,因為一旦有進程切換,釋放老指針的回調函數就有可能被調用,從而導致老指針被釋放掉,當被切換掉的進程被重新調度運行時它就有可能引用到一個被釋放掉的內存空間。
現在我們看到為什麽rcu_read_lock只需要關閉內核可搶占性就可以了,因為它使得即便在臨界區中發生了中斷,當前進程也不可能被切換除去。 內核開發者,確切地說,RCU的設計者所能做的只能到這個程度。接下來就是使用者的責任了,如果在rcu的臨界區中調用了一個函數,該函數可能睡眠,那麽RCU的設計規則就遭到了破壞,系統將進入一種不穩定的狀態。
這再次說明,如果想使用一個東西,一定要搞清楚其內在的機制,象上面剛提到的那個例子,即便現在程序不出現問題,但是系統中留下的隱患如同一個定時炸彈, 隨時可能被引爆,尤其是過了很長時間問題才突然爆發出來。絕大多數情形下,找到問題所花費的時間可能要遠遠大於靜下心來仔細搞懂RCU的原理要多得多。
RCU中的讀取者相對rwlock的讀取者而言,自由度更高。因為RCU的讀取者在訪問一個共享資源時,不需要考慮寫入者的感受,這不同於rwlock的寫入者,rwlock reader在讀取共享資源時需要確保沒有寫入者在操作該資源。兩者之間的差異化源自RCU對共享資源在讀取者與寫入者之間進行了分離,而rwlock的 讀取者和寫入者則至始至終只使用共享資源的一份拷貝。這也意味著RCU中的寫入者要承擔更多的責任,而且對同一共享資源進行更新的多個寫入者之間必須引入某種互斥機制,所以RCU屬於一種"免鎖機制"的說法僅限於讀取者與寫入者之間。所以我們看到:RCU機制應該用在有大量的讀取操作,而更新操作相對較少的情形下。此時RCU可以大大提升系統系能,因為RCU的讀取操作相對其他一些有鎖機制而言,在鎖上的開銷幾乎沒有。
實際使用中,共享的資源常常以鏈表的形式存在,內核為RCU模式下的鏈表操作實現了幾個接口函數,讀取者和使用者應該使用這些內核函數,比如 list_add_tail_rcu, list_add_rcu,hlist_replace_rcu等等,具體的使用可以參考某些內核編程或者設備驅動程序方面的資料。
在釋放老指針方面,Linux內核提供兩種方法供使用者使用,一個是調用call_rcu,另一個是調用synchronize_rcu。前者是一種異步 方式,call_rcu會將釋放老指針的回調函數放入一個結點中,然後將該結點加入到當前正在運行call_rcu的處理器的本地鏈表中,在時鐘中斷的 softirq部分(RCU_SOFTIRQ), rcu軟中斷處理函數rcu_process_callbacks會檢查當前處理器是否經歷了一個休眠期(quiescent,此處涉及內核進程調度等方面的內容),rcu的內核代碼實現在確定系統中所有的處理器都經歷過了一個休眠期之後(意味著所有處理器上都發生了一次進程切換,因此老指針此時可以被安全釋放掉了),將調用call_rcu提供的回調函數。
synchronize_rcu的實現則利用了等待隊列,在它的實現過程中也會向call_rcu那樣向當前處理器的本地鏈表中加入一個結點,與 call_rcu不同之處在於該結點中的回調函數是wakeme_after_rcu,然後synchronize_rcu將在一個等待隊列中睡眠,直到系統中所有處理器都發生了一次進程切換,因而wakeme_after_rcu被rcu_process_callbacks所調用以喚醒睡眠的 synchronize_rcu,被喚醒之後,synchronize_rcu知道它現在可以釋放老指針了。
所以我們看到,call_rcu返回後其註冊的回調函數可能還沒被調用,因而也就意味著老指針還未被釋放,而synchronize_rcu返回後老指針肯定被釋放了。所以,是調用call_rcu還是synchronize_rcu,要視特定需求與當前上下文而定,比如中斷處理的上下文肯定不能使用 synchronize_rcu函數了。
(原文首發 www.embexperts.com論壇,此處略有改動)
轉自:http://blog.chinaunix.net/uid-23769728-id-3080134.html
RCU的設計思想比較明確,通過新老指針替換的方式來實現免鎖方式的共享保護。但是具體到代碼的層面,理解起來多少還是會有些困難。在《深入Linux設備驅動程序內核機制》第4章中,已經非常明確地敘述了RCU背後所遵循的規則,這些規則是從一個比較高的視角來看,因為我覺得過多的代碼分析反而容易讓讀者在細節上迷失方向。最近拿到書後,我又重頭仔細看了RCU部分的文字,覺得還應該補充一點點內容,因為有些東西不一定適合寫在書裏。
RCU讀取側進入臨界區的標誌是調用rcu_read_lock,這個函數的代碼是:
- <include/linux/rcupdate.h>
- static inline void rcu_read_lock(void)
- {
- __rcu_read_lock();
- __acquire(RCU);
- rcu_read_acquire();
- }
接下來關於RCU一個有趣的問題是:何時才能釋放老指針。我見過很多書中對此的回答是:當系統中所有處理器上都發生了一次進程切換。這種程式化的回答常常讓剛接觸RCU機制的讀者感到一頭霧水,為什麽非要等所有處理器上都發生一次進程切換才可以調用回調函數釋放老指針呢?這其實是RCU的設計規則決定的: 所有對老指針的引用只可能發生在rcu_read_lock與rcu_read_unlock所包括的臨界區中,而在這個臨界區中不可能發生進程切換,而一旦出了該臨界區就不應該再有任何形式的對老指針p的引用。很明顯,這個規則要求讀取者在臨界區中不能發生進程切換,因為一旦有進程切換,釋放老指針的回調函數就有可能被調用,從而導致老指針被釋放掉,當被切換掉的進程被重新調度運行時它就有可能引用到一個被釋放掉的內存空間。
現在我們看到為什麽rcu_read_lock只需要關閉內核可搶占性就可以了,因為它使得即便在臨界區中發生了中斷,當前進程也不可能被切換除去。 內核開發者,確切地說,RCU的設計者所能做的只能到這個程度。接下來就是使用者的責任了,如果在rcu的臨界區中調用了一個函數,該函數可能睡眠,那麽RCU的設計規則就遭到了破壞,系統將進入一種不穩定的狀態。
這再次說明,如果想使用一個東西,一定要搞清楚其內在的機制,象上面剛提到的那個例子,即便現在程序不出現問題,但是系統中留下的隱患如同一個定時炸彈, 隨時可能被引爆,尤其是過了很長時間問題才突然爆發出來。絕大多數情形下,找到問題所花費的時間可能要遠遠大於靜下心來仔細搞懂RCU的原理要多得多。
RCU中的讀取者相對rwlock的讀取者而言,自由度更高。因為RCU的讀取者在訪問一個共享資源時,不需要考慮寫入者的感受,這不同於rwlock的寫入者,rwlock reader在讀取共享資源時需要確保沒有寫入者在操作該資源。兩者之間的差異化源自RCU對共享資源在讀取者與寫入者之間進行了分離,而rwlock的 讀取者和寫入者則至始至終只使用共享資源的一份拷貝。這也意味著RCU中的寫入者要承擔更多的責任,而且對同一共享資源進行更新的多個寫入者之間必須引入某種互斥機制,所以RCU屬於一種"免鎖機制"的說法僅限於讀取者與寫入者之間。所以我們看到:RCU機制應該用在有大量的讀取操作,而更新操作相對較少的情形下。此時RCU可以大大提升系統系能,因為RCU的讀取操作相對其他一些有鎖機制而言,在鎖上的開銷幾乎沒有。
實際使用中,共享的資源常常以鏈表的形式存在,內核為RCU模式下的鏈表操作實現了幾個接口函數,讀取者和使用者應該使用這些內核函數,比如 list_add_tail_rcu, list_add_rcu,hlist_replace_rcu等等,具體的使用可以參考某些內核編程或者設備驅動程序方面的資料。
在釋放老指針方面,Linux內核提供兩種方法供使用者使用,一個是調用call_rcu,另一個是調用synchronize_rcu。前者是一種異步 方式,call_rcu會將釋放老指針的回調函數放入一個結點中,然後將該結點加入到當前正在運行call_rcu的處理器的本地鏈表中,在時鐘中斷的 softirq部分(RCU_SOFTIRQ), rcu軟中斷處理函數rcu_process_callbacks會檢查當前處理器是否經歷了一個休眠期(quiescent,此處涉及內核進程調度等方面的內容),rcu的內核代碼實現在確定系統中所有的處理器都經歷過了一個休眠期之後(意味著所有處理器上都發生了一次進程切換,因此老指針此時可以被安全釋放掉了),將調用call_rcu提供的回調函數。
synchronize_rcu的實現則利用了等待隊列,在它的實現過程中也會向call_rcu那樣向當前處理器的本地鏈表中加入一個結點,與 call_rcu不同之處在於該結點中的回調函數是wakeme_after_rcu,然後synchronize_rcu將在一個等待隊列中睡眠,直到系統中所有處理器都發生了一次進程切換,因而wakeme_after_rcu被rcu_process_callbacks所調用以喚醒睡眠的 synchronize_rcu,被喚醒之後,synchronize_rcu知道它現在可以釋放老指針了。
所以我們看到,call_rcu返回後其註冊的回調函數可能還沒被調用,因而也就意味著老指針還未被釋放,而synchronize_rcu返回後老指針肯定被釋放了。所以,是調用call_rcu還是synchronize_rcu,要視特定需求與當前上下文而定,比如中斷處理的上下文肯定不能使用 synchronize_rcu函數了。
(原文首發 www.embexperts.com論壇,此處略有改動)
再談Linux內核中的RCU機制