1. 程式人生 > >Linux RCU 機制詳解

Linux RCU 機制詳解

性能 分享 源代碼 space led 訂閱 sign 程序 spa

1、簡介:

RCU(Read-Copy Update)是數據同步的一種方式,在當前的Linux內核中發揮著重要的作用。

RCU主要針對的數據對象是鏈表,目的是提高遍歷讀取數據的效率,為了達到目的使用RCU機制讀取數據的時候不對鏈表進行耗時的加鎖操作。這樣在同一時間可以有多個線程同時讀取該鏈表,並且允許一個線程對鏈表進行修改(修改的時候,需要加鎖)。

2、應用場景:

RCU適用於需要頻繁的讀取數據,而相應修改數據並不多的情景,例如在文件系統中,經常需要查找定位目錄,而對目錄的修改相對來說並不多,這就是RCU發揮作用的最佳場景。

3、相應資料:

Linux內核源碼當中,關於RCU的文檔比較齊全,你可以在 /Documentation/RCU/ 目錄下找到這些文件。

Paul E. McKenney 是內核中RCU源碼的主要實現者,他也寫了很多RCU方面的文章。他把這些文章和一些關於RCU的論文的鏈接整理到了一起。相應鏈接如下:

http://www2.rdrop.com/users/paulmck/RCU/

4、實現過程:

在RCU的實現過程中,我們主要解決以下問題:

1,在讀取過程中,另外一個線程刪除了一個節點。刪除線程可以把這個節點從鏈表中移除,但它不能直接銷毀這個節點,必須等到所有的讀取線程讀取完成以後,才進行銷毀操作。RCU中把這個過程稱為寬限期(Grace period)。

2,在讀取過程中,另外一個線程插入了一個新節點,而讀線程讀到了這個節點,那麽需要保證讀到的這個節點是完整的。這裏涉及到了發布-訂閱機制(Publish-Subscribe Mechanism)。

3, 保證讀取鏈表的完整性。新增或者刪除一個節點,不至於導致遍歷一個鏈表從中間斷開。但是RCU並不保證一定能讀到新增的節點或者不讀到要被刪除的節點。

4.1 寬限期:

通過例子,方便理解這個內容。以下例子修改於Paul的文章。

 1 struct foo{
 2     int a;
 3     char b;
 4     long c;
 5 };
 6 
 7 DEFINE_SPINLOCK(foo_mutex);
 8 
 9 void foo_read(void)
10 {
11     foo *fp = gbl_foo;
12     if
( fp != NULL ) 13 { 14 dosomthing(fp->a, fp->b, fp->c); 15 } 16 } 17 18 void foo_update(foo * new_fp) 19 { 20 spin_lock(&foo_mutex); 21 foo *old_fp = gbl_foo; 22 gbl_foo = new_fp; 23 spin_unlock(&foo_mutex); 24 }

如上的程序,是針對於全局變量gbl_foo的操作。假設以下場景。有兩個線程同時運行 foo_ read和foo_update的時候,當foo_ read執行完賦值操作後,線程發生切換;此時另一個線程開始執行foo_update並執行完成。當foo_ read運行的進程切換回來後,運行dosomething 的時候,fp已經被刪除,這將對系統造成危害。為了防止此類事件的發生,RCU裏增加了一個新的概念叫寬限期(Grace period)。如下圖所示:

技術分享圖片

圖中每行代表一個線程,最下面的一行是刪除線程,當它執行完刪除操作後,線程進入了寬限期。寬限期的意義是,在一個刪除動作發生後,它必須等待所有在寬限期開始前已經開始的讀線程結束,才可以進行銷毀操作。這樣做的原因是這些線程有可能讀到了要刪除的元素。圖中的寬限期必須等待1和2結束;而讀線程5在寬限期開始前已經結束,不需要考慮;而3,4,6也不需要考慮,因為在寬限期結束後開始後的線程不可能讀到已刪除的元素。為此RCU機制提供了相應的API來實現這個功能。

 1 void foo_read(void)
 2 {
 3     rcu_read_lock();
 4     foo *fp = gbl_foo;
 5     if( fp != NULL )
 6         dosomthing(fp->a, fp->b, fp->c);
 7     rcu_read_unlock();
 8 }
 9 
10 void foo_update(foo *new_fp)
11 {
12     spin_lock(&foo_mutex);
13     foo *old_fp = gbl_foo;
14     gbl_foo = new_fp;
15     spin_unlock(&foo_mutex);
16     synchronize_rcu();
17     kfree(old_fp);
18 }

其中foo_read中增加了rcu_read_lock和rcu_read_unlock,這兩個函數用來標記一個RCU讀過程的開始和結束。其實作用就是幫助檢測寬限期是否結束。foo_update增加了一個函數synchronize_rcu(),調用該函數意味著一個寬限期的開始,而直到寬限期結束,該函數才會返回。我們再對比著圖看一看,線程1和2,在synchronize_rcu之前可能得到了舊的gbl_foo,也就是foo_update中的old_fp,如果不等它們運行結束,就調用kfee(old_fp),極有可能造成系統崩潰。而3,4,6在synchronize_rcu之後運行,此時它們已經不可能得到old_fp,此次的kfee將不對它們產生影響。

寬限期是RCU實現中最復雜的部分,原因是在提高讀數據性能的同時,刪除數據的性能也不能太差。

4.2 訂閱——發布機制:

當前使用的編譯器大多會對代碼做一定程度的優化,CPU也會對執行指令做一些優化調整,目的是提高代碼的執行效率,但這樣的優化,有時候會帶來不期望的結果。如例:

 1 void foo_update(foo *new_fp)
 2 {
 3     spin_lock(&foo_mutex);
 4     foo *old_fp = gbl_foo;
 5     
 6     new_fp->a = 1;
 7     new_fp->b = b;
 8     new_fp->c = 100;
 9     
10     gbl_foo = new_fp;
11     spin_unlock(&foo_mutex);
12     synchronize_rcu();
13     kfree(old_fp);
14 }

這段代碼中,我們期望的是6,7,8行的代碼在第10行代碼之前執行。但優化後的代碼並不對執行順序做出保證。在這種情形下,一個讀線程很可能讀到 new_fp,但new_fp的成員賦值還沒執行完成。當讀線程執行dosomething(fp->a, fp->b , fp->c ) 的 時候,就有不確定的參數傳入到dosomething,極有可能造成不期望的結果,甚至程序崩潰。可以通過優化屏障來解決該問題,RCU機制對優化屏障做了包裝,提供了專用的API來解決該問題。這時候,第十行不再是直接的指針賦值,而應該改為 :

rcu_assign_pointer(gbl_foo,new_fp);

rcu_assign_pointer的實現比較簡單,如下:

1 #define rcu_assign_pointer(p, v) 2     __rcu_assign_pointer((p), (v), __rcu)

1 #define RCU_INIT_POINTER(p, v) 2         p = (typeof(*v) __force __rcu *)(v)

在DEC Alpha CPU機器上還有一種更強悍的優化,如下所示:

1 void foo_read(void)
2 {
3     rcu_read_lock();
4     foo *fp = gbl_foo;
5     if( fp != NULL )
6         dosomthing(fp->a, fp->b, fp->c);
7     rcu_read_unlock();
8 }

第六行的 fp->a,fp->b,fp->c會在第3行還沒執行的時候就預先判斷運行,當他和foo_update同時運行的時候,可能導致傳入dosomething的一部分屬於舊的gbl_foo,而另外的屬於新的。這樣導致運行結果的錯誤。為了避免該類問題,RCU還是提供了宏來解決該問題:

 1 #define rcu_dereference_check(p, c)  2     __rcu_dereference_check((p), rcu_read_lock_held() || (c), __rcu)
 3 
 4 #define __rcu_dereference_check(p, c, space)  5     ({  6         typeof(*p) *_________p1 = (typeof(*p)*__force )ACCESS_ONCE(p);  7         rcu_lockdep_assert(c, "suspicious rcu_dereference_check()"  8                       " usage");  9         rcu_dereference_sparse(p, space); 10         smp_read_barrier_depends(); 11         ((typeof(*p) __force __kernel *)(_________p1)); 12     })
13 
14 static inline int rcu_read_lock_held(void)
15 {
16     if (!debug_lockdep_rcu_enabled())
17         return 1;
18     if (rcu_is_cpu_idle())
19         return 0;
20     if (!rcu_lockdep_current_cpu_online())
21         return 0;
22     return lock_is_held(&rcu_lock_map);
23 }

這段代碼中加入了調試信息,去除調試信息,可以是以下的形式(其實這也是舊版本中的代碼):

1 #define rcu_dereference_check(p) ({2                                     typeof(p) _____p1  = p; 3                                     smp_read_barrier_depends(); 4                                     (_____p1); 5                                   })

在賦值後加入優化屏障smp_read_barrier_depends()。

我們之前的第四行代碼改為 foo *fp = rcu_dereference(gbl_foo);,就可以防止上述問題。

4.3 數據讀取的完整性:

還是通過例子來說明這個問題:

技術分享圖片

如圖我們在原list中加入一個節點new到A之前,所要做的第一步是將new的指針指向A節點,第二步才是將Head的指針指向new。這樣做的目的是當插入操作完成第一步的時候,對於鏈表的讀取並不產生影響,而執行完第二步的時候,讀線程如果讀到new節點,也可以繼續遍歷鏈表。如果把這個過程反過來,第一步head指向new,而這時一個線程讀到new,由於new的指針指向的是Null,這樣將導致讀線程無法讀取到A,B等後續節點。從以上過程中,可以看出RCU並不保證讀線程讀取到new節點。如果該節點對程序產生影響,那麽就需要外部調用做相應的調整。如在文件系統中,通過RCU定位後,如果查找不到相應節點,就會進行其它形式的查找,相關內容等分析到文件系統的時候再進行敘述。

我們再看一下刪除一個節點的例子:

技術分享圖片

如圖我們希望刪除B,這時候要做的就是將A的指針指向C,保持B的指針,然後刪除程序將進入寬限期檢測。由於B的內容並沒有變更,讀到B的線程仍然可以繼續讀取B的後續節點。B不能立即銷毀,它必須等待寬限期結束後,才能進行相應銷毀操作。由於A的節點已經指向了C,當寬限期開始之後所有的後續讀操作通過A找到的是C,而B已經隱藏了,後續的讀線程都不會讀到它。這樣就確保寬限期過後,刪除B並不對系統造成影響。

5、小結:

RCU的原理並不復雜,應用也很簡單。但代碼的實現確並不是那麽容易,難點都集中在了寬限期的檢測上,後續分析源代碼的時候,我們可以看到一些極富技巧的實現方式。

Linux RCU 機制詳解