Linux作業系統線程庫效能測試與分析

NPTL 成為 glibc "正選" 線程庫後，它的效能如何受到很多人的關注。本文就針對 NPTL 與 LinuxThreads 的效能比較，以及超執行緒、核心可搶佔等特性對線程效能的影響進行了全面評測。

一、 前言

在 Linux 2.6.x 核心中，調度效能的改進是其中最令人信服的一部分 [1]。NPTL（Native Posix Thread Library）[2] 使用核心的新特性重寫了 Linux 的線程庫，取代曆史悠久而備受爭議的 LinuxThreads [3] 成為 glibc 的首選線程庫。

NPTL 的效能究竟如何？相對 LinuxThreads 又有哪些明顯的改進？在對 NPTL 進行全面分析之前，本文針對這兩種線程庫，以及核心中 "核心可搶佔"（Preemptible）和超執行緒（HyperThreading）[4] 等特性進行了全面的效能評測，結果表明 NPTL 絕對值得廣大伺服器系統期待和使用。

二、 Benchmark

1. 測試平台

進行本測試的硬體平台為浪潮 NF420R 伺服器 [7]，4 個 Hyperthreading-enabled Intel Xeon 2.2G 處理器，4G 記憶體。Linux 選擇了 Slackware 9.0 發行版 [8]，所使用的核心源碼來自www.kernel.org。

2. 針對測試：LMBench

lmbench 是一個用於評價系統綜合效能的多平台開源 benchmark [5]，但其中沒有對線程的支援。其中有兩個測試進程效能的 benchmark：lat_proc 用於評測進程建立和終止的效能，lat_ctx 用於評測進程切換的開銷。lmbench 擁有良好的 benchmark 結構，只需要修改具體的 Target 程式（如 lat_proc.c 和 lat_ctx.c），就可以借用 lmbench 的計時、統計系統得到我們關心的線程庫效能的資料。

基於 lat_proc和lat_ctx 的演算法，本文實現了 lat_thread和lat_thread_ctx 兩個 benchmark。在 lat_thread 中，lat_proc 被改造成使用線程，用 pthread_create() 替代了 fork()，用 pthread_join() 替代 wait()；在 lat_thread_ctx 中，沿用 lat_ctx 的評測演算法（見 lat_ctx 手冊頁），將建立進程的過程改寫為建立線程，仍然使用管道進行通訊和同步。

lat_thread null

 

null 參數表示線程不進行任何實際操作，建立後即刻返回。

lat_thread_ctx -s #threads

 

size 參數與 lat_ctx 定義相同，可表示線程的大小（實際編程時為分配 K 資料；#threads 參數為線程數，即參與令牌傳遞的線程總數，相當於程式負載情況。

3. 綜合測試：Volanomark

volanomark是一個純java的benchmark，專門用於測試系統調度器和線程環境的綜合效能[6]，它建立一個類比Client/Server方式的Java聊天室，通過擷取每秒平均發送的訊息數來評測宿主機綜合效能（數值越大效能越好）。Volanomark測試與Java虛擬機器平台相關，本文使用Sun Java SDK 1.4.2作為測試用Java平台，Volanomark版本2.5.0.9。

三、 測試結果

測試計劃中將核心分為 2.4.26、2.6.6/ 支援核心搶佔和 2.6.6/ 不支援核心搶佔三類；通過配置核心以及 NF420R 的 BIOS 實現三類 SMP 規模：單處理機 (UP)、4CPU 的 SMP（SMP4）和開啟超執行緒支援的虛擬 8CPU SMP（SMP8*）。核心配置和 SMP 規模的每一種組合都針對 LinuxThreads 和 NPTL 使用 lat_thread、lat_thread_ctx 和 volanomark 擷取一組資料。由於 NPTL 無法在 2.4.x 核心上使用，該項資料空缺。