How does proc stats work
I have done a lot of reading and testing of the proc directory in OS’s using the Linux kernel. I have been using Linux myself for many years now, but I needed to get into more details for a small private project. Specifically how the stat files work. I knew the basics, but not enough to create actual calculations with the data in them. The problem is that the files in proc does not seem to contain what they should, not according to what I have read vs. my tests. For example: the CPU line in the root stat file should contain the total uptime for the CPU times the amount of cores (and/or amount of CPU’s) in jiffies. So to get the system uptime, you would have to add each number in the row to each other, divide by the number of cores/CPU’s and again divide by whatever a jiffie is defined to be on that particular system. At least this is the formula that I keep finding when searching this subject. If this was true, then the result should be equal to the first number in /proc/uptime? But this is not the case, and I have tested this on several machines with different amount of cores, both 32bit and 64bit systems. I can never get these two to match up. Also the stat file for each pid have an uptime part (part 21 I think it was). But I cannot figure out what this number should be matched against to calculate a process uptime in seconds. So far what I have read, it should contain the total cpu jiffies as they was when the process was started. So if this is true, then one would simply substract this from the current total cpu jiffies and divide this with whatever a jiffie is on that system? But again, I cannot seam to get this to add up to reality. Then there is the problem with finding out what a jiffie is. I found a formula where /proc/stat was used together with /proc/uptime and some dividing with the amount of cores/CPU’s to get that number. But this does not work. And I would not expect it to when the values of those two files does not add up, like mentioned in my first problem above. I did however come up with a different approach. Simply reading the first line of /proc/stat twice within a second. Then I could just compare and see how many jiffies the system had added in that second and divide that with the number of cores. This works on normal Linux systems, but it fails on Android in most cases. Android is constantly attaching/detaching cores depending on needs, which means that it differs how much you have to divide with. It is no problem as long as the core count matches both reads, but if one core goes active during the second read, it does not work. And last. I do not quite get the part by dividing by amount of cores. If each core writes all of it’s work time and idle time to the total line in /proc/stat, then it would make sense as that line would actually contain the total uptime times the amount of cores. But if this was true then each of the cpu lines would add up to the same number, but they don’t. This means that dividing by amount of cores should provide an incorrect result. But that would also mean that cpu monitor tools are making calculation errors, as they all seam to use this method. Example: /proc/stat
cpu 20455737 116285 4584497 104527701 1388173 366 102373 0 0 0 cpu0 4833292 5490 1413887 91023934 1264884 358 94250 0 0 0 cpu1 5785289 47944 1278053 4439797 45015 1 4235 0 0 0 cpu2 4748431 20922 926839 4552724 33455 2 2745 0 0 0 cpu3 5088724 41928 965717 4511246 44819 3 1141 0 0 0 The lines cpu0, cpu1, cpu2 and cpu3 does not add up to the same total result. This means that using the total result of the general cpu line divided by 4 should be incorrect. /proc/uptime
All of the above output was taken from a system that should be using clock ticks of 100. Now if you take the result of the general cpu line, divide that with 100 and then with 4 (amount of cores), you will not get the result of the uptime file. And if you take the result of the general cpu line, divide that with the uptime from /proc/uptime and then with 4 (amount of cores), you will not get the 100 that is this kernels clock ticks. So why is nothing adding up as it should? How do I get the clock ticks of a kernel, even on systems that attaches/detaches cores constantly? How to I get the total real uptime of a process? How do I get the real uptime from /proc/stat?
Linux process stat file
| www.LinuxHowtos.org howtos, tips&tricks and tutorials for linux |  | |
 |  | |
using iotop to find disk usage hogs
average rating: 1.8 (88 votes) (1=very good 6=terrible)
Workaround and fixes for the current Core Dump Handling vulnerability affected kernels
average rating: 1.3 (28 votes) (1=very good 6=terrible)
/proc/stat explained
Various pieces of information about kernel activity are available in the
/proc/stat file.
All of the numbers reported in this file are aggregates since the system first booted.
For a quick look, simply cat the file:
> cat /proc/stat
cpu 2255 34 2290 22625563 6290 127 456
cpu0 1132 34 1441 11311718 3675 127 438
cpu1 1123 0 849 11313845 2614 0 18
intr 114930548 113199788 3 0 5 263 0 4 [. lots more numbers . ]
ctxt 1990473
btime 1062191376
processes 2915
procs_running 1
procs_blocked 0
The very first «cpu» line aggregates the numbers in all of the other «cpuN» lines.
These numbers identify the amount of time the CPU has spent performing different kinds of work. Time units are in USER_HZ or Jiffies (typically hundredths of a second).
- user: normal processes executing in user mode
- nice: niced processes executing in user mode
- system: processes executing in kernel mode
- idle: twiddling thumbs
- iowait: waiting for I/O to complete
- irq: servicing interrupts
- softirq: servicing softirqs
The «intr» line gives counts of interrupts serviced since boot time, for each
of the possible system interrupts. The first column is the total of all interrupts serviced; each subsequent column is the total for that particular interrupt.
The «ctxt» line gives the total number of context switches across all CPUs.
The «btime» line gives the time at which the system booted, in seconds since
the Unix epoch.
The «processes» line gives the number of processes and threads created, which includes (but is not limited to) those created by calls to the fork() and clone() system calls.
The «procs_running» line gives the number of processes currently running on CPUs.
The «procs_blocked» line gives the number of processes currently blocked, waiting for I/O to complete.
copied from the kernel documentation of the /proc filesystem
Note: On my 2.6.18 kernel, cpu lines have 8 numeric fields, not 7.
Wonder what that one means.
Note:
The 8th column is called steal_time. It counts the ticks spent
executing other virtual hosts (in virtualised environments like Xen)
Note2:
With Linux 2.6.24 there is 9th column for (virtual) guest systems. See man 5 proc.
rate this article:
current rating: average rating: 1.6 (2083 votes) (1=very good 6=terrible)
Your rating:
| |
— Powered by — Running on —
Copyright 2004-2020 Sascha Nitsch Unternehmensberatung GmbH
: :
— Level Triple-A Conformance to Web Content Accessibility Guidelines 1.0 —
— Copyright and legal notices —
Time to create this page: 58.3 ms