nanosleep CPU使用率高?
我注意到,一个名为 nanosleep 的小测试程序在内核高于 2.6.22 的 Linux 机器上运行时,显示出 CPU 使用率的巨大差异。
#include <time.h>
int main (void)
{
struct timespec sleepTime;
struct timespec returnTime;
sleepTime.tv_sec = 0;
sleepTime.tv_nsec = 1000;
while (1)
{
nanosleep(&sleepTime, &returnTime);
}
return 0;
}
(是的,我意识到这个程序什么也不做)
如果我编译这个程序并在 openSUSE 10.3 机器(2.6.22.19-0.2-default)上运行它,该程序甚至不会出现在“top”生成的进程列表中,表明对我来说,它使用的 CPU 时间非常少。 如果我在 openSUSE 11.1 机器(2.6.27.23-0.1-default)上运行它,顶部显示该程序占用了 40% 的 CPU 时间。 在 Fedora 9 (2.6.25-14.fc9.i686) 和 Fedora 10 上运行时,在“top”中也显示出同样高的 CPU 使用率。
内核中是否发生了影响此问题的更改?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这是由于主线调度程序中引入了 NO_HZ。
以前,您的 1,000 ns 睡眠通常是睡眠一个完整的周期 - 1,000,000 ns。 现在,当机器处于闲置状态时,它实际上只是为了满足您的要求而休眠。 因此,它运行 while() 循环和系统调用的频率大约是 1,000 倍 - 因此 CPU 使用率更高。 如果增加 tv_nsec,您应该会看到 CPU 使用率减少。
This is due to the introduction of NO_HZ into the mainline scheduler.
Previously, your 1,000 ns sleep was usually sleeping for a whole tick - 1,000,000 ns. Now, when the machine is otherwise idle, it's actually only sleeping for what you asked for. So it's running the while() loop and syscall around 1,000 times more frequently - hence a lot more CPU usage. If you increase tv_nsec you should see a reduction in the CPU usage.
我没有明确的答案......但我首先要查看的是编译内核的配置选项:
我认为可能相关的选项是
CONFIG_HZ
,CONFIG_HPET_TIMER
和CONFIG_HIGH_RES_TIMERS
。 也许您的内核之间的差异......这可能会帮助您缩小范围。过去在 2.4 内核上,如果在实时调度程序策略(
SCHED_FIFO
或SCHED_RR
)下运行,nanosleep 会忙等待 2 毫秒以下的等待,请参阅nanosleep 手册页),但是由于所有内核都是2.6,这似乎不是一个因素。I don't have a definitive answer... but the first thing I would look at is the config options with which the kernel was compiled:
Options that I think might be relevant are
CONFIG_HZ
,CONFIG_HPET_TIMER
andCONFIG_HIGH_RES_TIMERS
. Maybe those differ among your kernels... that might help you narrow it down.It used to be on 2.4 kernels that nanosleep would busy-wait for waits of under 2 ms if running under real-time scheduler policies (
SCHED_FIFO
orSCHED_RR
, see the nanosleep man page), but since all of the kernels are 2.6, that doesn't seem to be a factor.