Linux 第二次读取Proc FS文件时使用lseek（）安全吗 对/proc/stat文件使用lseek（fd，0）然后读取（fd，buf）是否安全，而不是下次重新打开以获取此文件的更新内容 打开此文件后，mmap（）调用的真正作用是什么（见下文）

我遇到的问题是top报告的CPU使用率太低（软件中断为10%对100%）。strace表示top不会重新打开此文件，而是返回开始并再次读取。不知何故，下次从该文件读取的内容与我单独运行cat for

/proc/stat

文件时得到的内容不匹配

另外，如果我在一个循环中同时运行top和cat

/proc/stat

，那么top开始报告正确的CPU使用情况

我发现的另一个区别是，top在打开

/proc/stat

文件后立即使用

mmap（）

调用，而

cat

则不这样做。我不确定这是否也与我的问题有关（因为

filesdes=-1

此处）：

---

我正在使用Ubuntu10.04.1桌面版和2.6.32-27服务器映像。CPU是Intel Q6600。

你问的问题很有趣。。。我开始检查我的机器，但我没有看到cat/proc/stat和executetop之间的区别。不管怎样，我在工作，我不能完全“自由”进行测试

您描述的“刷新”打开的文件以读取新数据的方式是正确的。。。在[f | l]seek（）调用的情况下，先调用文件的结尾，然后调用文件的开头，将更新EOF并读取新数据

我不认为mmap（）调用会导致您提到的问题，它可以使读取速度更快，但除此之外（我不是100%确定）

我建议你用C语言制作一个小应用程序，打开/proc/stat，阅读它，寻找它，然后再阅读一遍，看看它是如何更新的，如果你有一些压力测试要做的话也会很有用

现在，回答你真正的问题：

是的，好吧，这是肯定的，因为您将“等待”文件中的新数据，这应该比一直打开和关闭文件要好

它将文件映射到进程地址空间，以下是一些信息和示例：

---

http://www.linuxquestions.org/questions/programming-9/mmap-tutorial-c-c-511265/

对于lseek来说确实如此。htop的实现似乎是在每次读取/proc/stat文件之前重新打开它，但同时htop也报告无效的cpu使用情况。所以我们可以排除lseek（）。

mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7b37649000