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 参数为线程数,即参与令牌传递的线程总数,相当于程序负载情况。