lseek(fd,0)
and then read(fd,buf)
for /proc/stat
file instead of reopening it to get updated contents of this file next time?mmap()
call after opening this file really do (see below)?The problem I am encountering is that top reports way too low CPU usage (10% vs 100% for software interrupts). The strace indicates that top does not reopen this file but instead lseeks to beginning and reads it once again. And somehow the contents which are read from this file next time does not match with what I would get when I run cat for /proc/stat
file alone.
Also If I run top and cat /proc/stat
in a loop at the same time then top starts to report correct CPU-Usage.
One more difference I spot is that top uses mmap()
call right after opening the /proc/stat
file, while cat
does not do that. I am not sure if this also could be related with my problem (because filesdes=-1
here):
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7b37649000
I am using Ubuntu 10.04.1 Desktop edition with 2.6.32-27-server image. The CPU is Intel Q6600.
It contains useful information about the processes that are currently running, it is regarded as control and information center for kernel. The proc file system also provides communication medium between kernel space and user space.
proc is a special file system and is not associated with any hard drive device. Certian files inside /proc can be modified to change the behaviour of a running kernel. For example, /proc/sys/ files. Most of the system monitoring commands like ps, top, free, etc use process files inside /proc/ to fetch information.
The /proc/PID/maps file contains the currently mapped memory regions and their access permissions. or if empty, the mapping is anonymous.
It's very interesting what you ask... I start checking in my machine but I don't see differences between cat /proc/stat and execute top. Anyway, I'm at work and I'm not totally 'free' to make tests.
The way you describe to 'refresh' the opened file to read new data is correct... in case of a [f|l]seek() call to the end and then to the beginning of the file will update the EOF and new data will be read.
I don't think that the mmap() call will cause the problem you mentioned, it could make the read faster, but nothing else (I'm not 100% sure).
I would suggest you to make a small app in C that open /proc/stat, read it, seek it and read it again to see how it's updated, also if you have some stress test to do could be useful.
Now, answering your real questions:
Yes, AFAIK it's sure because you will be 'waiting' for new data on the file and it should be better than open and close the file all the time.
It maps a file to the process address space, here are some info and examples:
http://www.gnu.org/s/libc/manual/html_node/Memory_002dmapped-I_002fO.html http://www.linuxquestions.org/questions/programming-9/mmap-tutorial-c-c-511265/
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With