我注意到当Linux futexes竞争时,系统花费了很多时间在自旋锁上。即使没有直接使用futexes,也在调用malloc/free、rand、glib mutex calls等系统/库调用时出现问题,并进行调用futex。有任何方法可以消除这种行为吗?
我正在使用内核版本为2.6.32-279.9.1.el6.x86_64的CentOS 6.3,我还尝试了从kernel.org直接下载的最新稳定内核3.6.6。
原本,这个问题发生在一个具有16GB RAM的24核服务器上。该进程有700个线程。使用"perf record"收集的数据显示自旋锁是从futex中调用__lll_lock_wait_private和__lll_unlock_wake_private的,并正在占用50%的CPU时间。当我使用gdb停止进程时,回溯显示__lll_lock_wait_private __lll_unlock_wake_private的调用来自malloc和free。
我试图减少问题,所以编写了一个简单的程序来展示确实是futexes导致自旋锁问题。
启动8个线程,每个线程执行以下操作:
//...
static GMutex *lMethodMutex = g_mutex_new ();
while (true)
{
static guint64 i = 0;
g_mutex_lock (lMethodMutex);
// Perform any operation in the user space that needs to be protected.
// The operation itself is not important. It's the taking and releasing
// of the mutex that matters.
++i;
g_mutex_unlock (lMethodMutex);
}
//...
我正在一台8核机器上运行,内存充足。
使用"top"命令,我观察到机器有10%的空闲时间,10%的时间处于用户模式,90%的时间处于系统模式。
使用"perf top"命令,我观察到以下内容:
50.73% [kernel] [k] _spin_lock
11.13% [kernel] [k] hpet_msi_next_event
2.98% libpthread-2.12.so [.] pthread_mutex_lock
2.90% libpthread-2.12.so [.] pthread_mutex_unlock
1.94% libpthread-2.12.so [.] __lll_lock_wait
1.59% [kernel] [k] futex_wake
1.43% [kernel] [k] __audit_syscall_exit
1.38% [kernel] [k] copy_user_generic_string
1.35% [kernel] [k] system_call
1.07% [kernel] [k] schedule
0.99% [kernel] [k] hash_futex
我期望这段代码在自旋锁中花费一些时间,因为futex代码必须获取futex等待队列。我也期望这段代码在系统中花费一些时间,因为在这段代码片段中,在用户空间中运行的代码非常少。然而,在自旋锁中花费50%的时间似乎过多,特别是当这个CPU时间需要用于其他有用的工作时。