ARM上的Linux“top”实用程序报告我们已验证错误的数字.为什么？

我们有一个基于ARM9的嵌入式主板,运行 Linux 2.6.32.20.该设备是一个摄像机,其相关的捕获/压缩硬件将数据放入ARM存储器中的输入FIFO,然后ARM从用户空间访问.我们还有一个用于高级控制的编码器驱动程序.

应用程序级代码中的一个线程检查此用户空间fifo,当有数据时,它通过套接字发送出去.为了避免这个线程需要为数据轮询用户空间fifo的开销,我们对驱动程序进行了一次非常简单的read()调用,实际上它只是在FIFO中有任何数据时才会被挂起(没有任何内容真正“读入”到read()调用中提供的缓冲区.然后,此read()调用返回,并且线程继续从fifo读取数据,直到它为空,然后通过调用伪read()调用再次挂起.

通过在检测到帧丢失之前可以传输多少网络流来测量该系统是非常有效的.但我们已经确定使用假的read()调用会导致Linux“top”实用程序报告我们的应用程序的大量CPU使用情况.

我们已经构建了2个版本的应用程序 – 一个操作如上,另一个是相同的,除了它从不调用假读取(),而是通过介入的usleep()调用轮询fifo.当我们查看“top”报告的CPU使用情况时,对于2个情况,当每个发送5个流时,我们得到：

1)read()版本：CPU 12％
2)usleep()版本：CPU 4％

当然,现实中的轮询效率较低,如果我们忽略“顶级”所说的内容,而只是测量两个版本在我们看到帧丢失之前可以传输多少个同时网络流,那么上面的版本1获胜.

我们已经验证上面的read()调用是否正常运行.如果某个bug导致read()调用立即返回,即使fifo中没有数据,那么该线程最终会进行昂贵的连续轮询.但这种情况并非如此; read()调用使线程每秒正好运行30次.

我们认为我们的玩具busybox版本的“top”可能会有一些快捷方式 – 但是这些结果都没有在/ proc // stat中的原始数字中用于计算其显示的数字.

这个问题必须限制Linux内核本身如何收集/ proc // stat中显示的数字.

如果有人理解为什么会这样,请指出我正确的方向.
谢谢！