Why is the sum of /proc/pid/stat CPU greater than /proc/stat
Clash Royale CLAN TAG#URR8PPP
In /proc/<pid>/stat I add user cpu, system cpu, child user and child system cpu together for all processes. I take a delta from a previous sample.
Immediately after I sum the user, nice and system CPU from /proc/stat which should be for the entire box. Again I take a delta.
The sum from the processes is almost always slightly greater than that for the overall processor and I can't figure out why.
proc
edited Jan 17 at 17:01
Guss
6,18111325
asked Jan 16 at 16:04
user331809user331809
41
add a comment |
In /proc/<pid>/stat I add user cpu, system cpu, child user and child system cpu together for all processes. I take a delta from a previous sample.
Immediately after I sum the user, nice and system CPU from /proc/stat which should be for the entire box. Again I take a delta.
The sum from the processes is almost always slightly greater than that for the overall processor and I can't figure out why.
proc
edited Jan 17 at 17:01
Guss
6,18111325
asked Jan 16 at 16:04
user331809user331809
41
I ran another test where I drove a single process to have 100% CPU on one of the four cores and measured just that process and /proc/stat. The box was otherwise idle. The process registered 100 clock ticks per second normally (expected) and occasionally 101 ticks. When it registered 101, that extra one never accumulated in /proc/stat which kept going up 100 ticks every second. It appears it sometimes misses them.
– user331809
Jan 17 at 15:23
add a comment |
In /proc/<pid>/stat I add user cpu, system cpu, child user and child system cpu together for all processes. I take a delta from a previous sample.
Immediately after I sum the user, nice and system CPU from /proc/stat which should be for the entire box. Again I take a delta.
The sum from the processes is almost always slightly greater than that for the overall processor and I can't figure out why.
proc
edited Jan 17 at 17:01
Guss
6,18111325
asked Jan 16 at 16:04
user331809user331809
41
In /proc/<pid>/stat I add user cpu, system cpu, child user and child system cpu together for all processes. I take a delta from a previous sample.
Immediately after I sum the user, nice and system CPU from /proc/stat which should be for the entire box. Again I take a delta.
The sum from the processes is almost always slightly greater than that for the overall processor and I can't figure out why.
proc
proc
edited Jan 17 at 17:01
Guss
6,18111325
asked Jan 16 at 16:04
user331809user331809
41
edited Jan 17 at 17:01
Guss
6,18111325
asked Jan 16 at 16:04
user331809user331809
41
edited Jan 17 at 17:01
Guss
6,18111325
edited Jan 17 at 17:01
Guss
6,18111325
edited Jan 17 at 17:01
Guss
6,18111325
6,18111325
asked Jan 16 at 16:04
user331809user331809
41
asked Jan 16 at 16:04
user331809user331809
41
asked Jan 16 at 16:04
user331809user331809
41
41
I ran another test where I drove a single process to have 100% CPU on one of the four cores and measured just that process and /proc/stat. The box was otherwise idle. The process registered 100 clock ticks per second normally (expected) and occasionally 101 ticks. When it registered 101, that extra one never accumulated in /proc/stat which kept going up 100 ticks every second. It appears it sometimes misses them.
– user331809
Jan 17 at 15:23
add a comment |
I ran another test where I drove a single process to have 100% CPU on one of the four cores and measured just that process and /proc/stat. The box was otherwise idle. The process registered 100 clock ticks per second normally (expected) and occasionally 101 ticks. When it registered 101, that extra one never accumulated in /proc/stat which kept going up 100 ticks every second. It appears it sometimes misses them.
– user331809
Jan 17 at 15:23
I ran another test where I drove a single process to have 100% CPU on one of the four cores and measured just that process and /proc/stat. The box was otherwise idle. The process registered 100 clock ticks per second normally (expected) and occasionally 101 ticks. When it registered 101, that extra one never accumulated in /proc/stat which kept going up 100 ticks every second. It appears it sometimes misses them.
– user331809
Jan 17 at 15:23
I ran another test where I drove a single process to have 100% CPU on one of the four cores and measured just that process and /proc/stat. The box was otherwise idle. The process registered 100 clock ticks per second normally (expected) and occasionally 101 ticks. When it registered 101, that extra one never accumulated in /proc/stat which kept going up 100 ticks every second. It appears it sometimes misses them.
– user331809
Jan 17 at 15:23
add a comment |
1 Answer
1
active
oldest
votes
There are a few reasons why that would be the case, the most obvious one is that the per-process accounting uses different logic for counting different things.
Two specific examples:
- The system
stathas anicecolumn that counts user time spent in nice tasks (lower priority) - which you didn't specify that you use, so I'm guessing you didn't sum it. In the process this will be counted as standard user time. iowaittime - which also you didn't account for - is likely counted in the processstatas system time. But its a bad idea to also count iniowaittime as it is very unreliable account of actual time, asman procexplains:
iowait (since Linux 2.5.41)
(5) Time waiting for I/O to complete. This value is not reliable, for the following reasons:
The CPU will not wait for I/O to complete; iowait is the time that a task is waiting for I/O to complete. When a CPU goes into idle state for outstanding task I/O, another task will be scheduled on this CPU.
On a multi-core CPU, the task waiting for I/O to complete is not running on any CPU, so the iowait of each CPU is difficult to calculate.
The value in this field may decrease in certain conditions.
Lastly, I have to note that I believe this type of accounting is useless as it can never be accurate enough for any serious purpose - system and process counters are processed in different parts of the system for different purposes and will never match to any useful degree.
answered Jan 17 at 17:11
GussGuss
6,18111325
Thank you, I suspect the last paragraph is the answer sadly though it boggles me that we just skip clock ticks sometimes. As for nice, yes I did say that I added it. And iowait, not added but I actually checked all the counters to make sure nothing unexpected was getting incremented and it was not. It would be a bug if this was counted as real CPU in the process.
– user331809
Jan 18 at 18:08
As far as I understand, iowait (D state in ps) is counted as process system time.
– Guss
Jan 18 at 19:20
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f494868%2fwhy-is-the-sum-of-proc-pid-stat-cpu-greater-than-proc-stat%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
There are a few reasons why that would be the case, the most obvious one is that the per-process accounting uses different logic for counting different things.
Two specific examples:
- The system
stathas anicecolumn that counts user time spent in nice tasks (lower priority) - which you didn't specify that you use, so I'm guessing you didn't sum it. In the process this will be counted as standard user time. iowaittime - which also you didn't account for - is likely counted in the processstatas system time. But its a bad idea to also count iniowaittime as it is very unreliable account of actual time, asman procexplains:
iowait (since Linux 2.5.41)
(5) Time waiting for I/O to complete. This value is not reliable, for the following reasons:
The CPU will not wait for I/O to complete; iowait is the time that a task is waiting for I/O to complete. When a CPU goes into idle state for outstanding task I/O, another task will be scheduled on this CPU.
On a multi-core CPU, the task waiting for I/O to complete is not running on any CPU, so the iowait of each CPU is difficult to calculate.
The value in this field may decrease in certain conditions.
Lastly, I have to note that I believe this type of accounting is useless as it can never be accurate enough for any serious purpose - system and process counters are processed in different parts of the system for different purposes and will never match to any useful degree.
answered Jan 17 at 17:11
GussGuss
6,18111325
Thank you, I suspect the last paragraph is the answer sadly though it boggles me that we just skip clock ticks sometimes. As for nice, yes I did say that I added it. And iowait, not added but I actually checked all the counters to make sure nothing unexpected was getting incremented and it was not. It would be a bug if this was counted as real CPU in the process.
– user331809
Jan 18 at 18:08
As far as I understand, iowait (D state in ps) is counted as process system time.
– Guss
Jan 18 at 19:20
add a comment |
There are a few reasons why that would be the case, the most obvious one is that the per-process accounting uses different logic for counting different things.
Two specific examples:
- The system
stathas anicecolumn that counts user time spent in nice tasks (lower priority) - which you didn't specify that you use, so I'm guessing you didn't sum it. In the process this will be counted as standard user time. iowaittime - which also you didn't account for - is likely counted in the processstatas system time. But its a bad idea to also count iniowaittime as it is very unreliable account of actual time, asman procexplains:
iowait (since Linux 2.5.41)
(5) Time waiting for I/O to complete. This value is not reliable, for the following reasons:
The CPU will not wait for I/O to complete; iowait is the time that a task is waiting for I/O to complete. When a CPU goes into idle state for outstanding task I/O, another task will be scheduled on this CPU.
On a multi-core CPU, the task waiting for I/O to complete is not running on any CPU, so the iowait of each CPU is difficult to calculate.
The value in this field may decrease in certain conditions.
Lastly, I have to note that I believe this type of accounting is useless as it can never be accurate enough for any serious purpose - system and process counters are processed in different parts of the system for different purposes and will never match to any useful degree.
answered Jan 17 at 17:11
GussGuss
6,18111325
Thank you, I suspect the last paragraph is the answer sadly though it boggles me that we just skip clock ticks sometimes. As for nice, yes I did say that I added it. And iowait, not added but I actually checked all the counters to make sure nothing unexpected was getting incremented and it was not. It would be a bug if this was counted as real CPU in the process.
– user331809
Jan 18 at 18:08
As far as I understand, iowait (D state in ps) is counted as process system time.
– Guss
Jan 18 at 19:20
add a comment |
There are a few reasons why that would be the case, the most obvious one is that the per-process accounting uses different logic for counting different things.
Two specific examples:
- The system
stathas anicecolumn that counts user time spent in nice tasks (lower priority) - which you didn't specify that you use, so I'm guessing you didn't sum it. In the process this will be counted as standard user time. iowaittime - which also you didn't account for - is likely counted in the processstatas system time. But its a bad idea to also count iniowaittime as it is very unreliable account of actual time, asman procexplains:
iowait (since Linux 2.5.41)
(5) Time waiting for I/O to complete. This value is not reliable, for the following reasons:
The CPU will not wait for I/O to complete; iowait is the time that a task is waiting for I/O to complete. When a CPU goes into idle state for outstanding task I/O, another task will be scheduled on this CPU.
On a multi-core CPU, the task waiting for I/O to complete is not running on any CPU, so the iowait of each CPU is difficult to calculate.
The value in this field may decrease in certain conditions.
Lastly, I have to note that I believe this type of accounting is useless as it can never be accurate enough for any serious purpose - system and process counters are processed in different parts of the system for different purposes and will never match to any useful degree.
answered Jan 17 at 17:11
GussGuss
6,18111325
There are a few reasons why that would be the case, the most obvious one is that the per-process accounting uses different logic for counting different things.
Two specific examples:
- The system
stathas anicecolumn that counts user time spent in nice tasks (lower priority) - which you didn't specify that you use, so I'm guessing you didn't sum it. In the process this will be counted as standard user time. iowaittime - which also you didn't account for - is likely counted in the processstatas system time. But its a bad idea to also count iniowaittime as it is very unreliable account of actual time, asman procexplains:
iowait (since Linux 2.5.41)
(5) Time waiting for I/O to complete. This value is not reliable, for the following reasons:
The CPU will not wait for I/O to complete; iowait is the time that a task is waiting for I/O to complete. When a CPU goes into idle state for outstanding task I/O, another task will be scheduled on this CPU.
On a multi-core CPU, the task waiting for I/O to complete is not running on any CPU, so the iowait of each CPU is difficult to calculate.
The value in this field may decrease in certain conditions.
Lastly, I have to note that I believe this type of accounting is useless as it can never be accurate enough for any serious purpose - system and process counters are processed in different parts of the system for different purposes and will never match to any useful degree.
answered Jan 17 at 17:11
GussGuss
6,18111325
answered Jan 17 at 17:11
GussGuss
6,18111325
answered Jan 17 at 17:11
GussGuss
6,18111325
answered Jan 17 at 17:11
GussGuss
6,18111325
6,18111325
Thank you, I suspect the last paragraph is the answer sadly though it boggles me that we just skip clock ticks sometimes. As for nice, yes I did say that I added it. And iowait, not added but I actually checked all the counters to make sure nothing unexpected was getting incremented and it was not. It would be a bug if this was counted as real CPU in the process.
– user331809
Jan 18 at 18:08
As far as I understand, iowait (D state in ps) is counted as process system time.
– Guss
Jan 18 at 19:20
add a comment |
Thank you, I suspect the last paragraph is the answer sadly though it boggles me that we just skip clock ticks sometimes. As for nice, yes I did say that I added it. And iowait, not added but I actually checked all the counters to make sure nothing unexpected was getting incremented and it was not. It would be a bug if this was counted as real CPU in the process.
– user331809
Jan 18 at 18:08
As far as I understand, iowait (D state in ps) is counted as process system time.
– Guss
Jan 18 at 19:20
Thank you, I suspect the last paragraph is the answer sadly though it boggles me that we just skip clock ticks sometimes. As for nice, yes I did say that I added it. And iowait, not added but I actually checked all the counters to make sure nothing unexpected was getting incremented and it was not. It would be a bug if this was counted as real CPU in the process.
– user331809
Jan 18 at 18:08
Thank you, I suspect the last paragraph is the answer sadly though it boggles me that we just skip clock ticks sometimes. As for nice, yes I did say that I added it. And iowait, not added but I actually checked all the counters to make sure nothing unexpected was getting incremented and it was not. It would be a bug if this was counted as real CPU in the process.
– user331809
Jan 18 at 18:08
As far as I understand, iowait (D state in ps) is counted as process system time.
– Guss
Jan 18 at 19:20
As far as I understand, iowait (D state in ps) is counted as process system time.
– Guss
Jan 18 at 19:20
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f494868%2fwhy-is-the-sum-of-proc-pid-stat-cpu-greater-than-proc-stat%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I ran another test where I drove a single process to have 100% CPU on one of the four cores and measured just that process and /proc/stat. The box was otherwise idle. The process registered 100 clock ticks per second normally (expected) and occasionally 101 ticks. When it registered 101, that extra one never accumulated in /proc/stat which kept going up 100 ticks every second. It appears it sometimes misses them.
– user331809
Jan 17 at 15:23