Is reading /proc repeatedly expensive?
Clash Royale CLAN TAG#URR8PPP
Since the contents of /proc live inside memory, how expensive is reading it's content repeatedly (every second for example)? And does a program like top, htop or atop do that (reading /proc in every given interval)?
proc
asked Dec 16 at 19:38
Mas Bagol
2932616
add a comment |
Since the contents of /proc live inside memory, how expensive is reading it's content repeatedly (every second for example)? And does a program like top, htop or atop do that (reading /proc in every given interval)?
proc
asked Dec 16 at 19:38
Mas Bagol
2932616
1
Note that/procdoesn't "live inside memory". When you interact with files in/proc, you call kernel functions, which supply the answer etc. The cost of this depends a lot on the function that is called. In many cases the cost is low.
– dirkt
Dec 17 at 9:07
add a comment |
Since the contents of /proc live inside memory, how expensive is reading it's content repeatedly (every second for example)? And does a program like top, htop or atop do that (reading /proc in every given interval)?
proc
asked Dec 16 at 19:38
Mas Bagol
2932616
Since the contents of /proc live inside memory, how expensive is reading it's content repeatedly (every second for example)? And does a program like top, htop or atop do that (reading /proc in every given interval)?
proc
proc
asked Dec 16 at 19:38
Mas Bagol
2932616
asked Dec 16 at 19:38
Mas Bagol
2932616
asked Dec 16 at 19:38
Mas Bagol
2932616
asked Dec 16 at 19:38
Mas Bagol
2932616
asked Dec 16 at 19:38
Mas Bagol
2932616
2932616
1
Note that/procdoesn't "live inside memory". When you interact with files in/proc, you call kernel functions, which supply the answer etc. The cost of this depends a lot on the function that is called. In many cases the cost is low.
– dirkt
Dec 17 at 9:07
add a comment |
1
Note that/procdoesn't "live inside memory". When you interact with files in/proc, you call kernel functions, which supply the answer etc. The cost of this depends a lot on the function that is called. In many cases the cost is low.
– dirkt
Dec 17 at 9:07
1
1
Note that
/proc doesn't "live inside memory". When you interact with files in /proc, you call kernel functions, which supply the answer etc. The cost of this depends a lot on the function that is called. In many cases the cost is low.– dirkt
Dec 17 at 9:07
Note that
/proc doesn't "live inside memory". When you interact with files in /proc, you call kernel functions, which supply the answer etc. The cost of this depends a lot on the function that is called. In many cases the cost is low.– dirkt
Dec 17 at 9:07
add a comment |
2 Answers
2
active
oldest
votes
Reading from /proc as a user every second is not expensive under normal conditions. There are however a couple of files that can be expensive because they require kernel-side locking that can delay other things.
E.g. this may be such a case: https://serverfault.com/questions/943866/proc-sys-net-netfilter-nf-conntrack-count-extreme-drop-when-reading-proc-net-n
Programs like top and conntrack will try to use other means (e.g. netlink) for multiple reasons:
/procis a text-based approach that's not 100% stable. A program needs to scan a file and parse it, hoping that it doesn't change across kernel versions- As mentioned, some /proc files may be expensive to read, also depending on their size
- The
netlinkapproach can return more information than/proc
answered Dec 16 at 19:55
V13
2,799613
1
The/procinterface is part of the kernel ABI, and therefore maintained with the same stability guarantees as system calls etc.
– Stephen Kitt
Dec 17 at 6:05
@StephenKitt that doesn't make it 100% stable though because the presence of some files depends on the kernel configuration. E.g. CONFIG_PROC_PID_CPUSET, CONFIG_PROC_CHILDREN, etc. Also doesn't ensure their presence across systems of the same kernel version.
– V13
Dec 19 at 1:41
That’s not specific to/proc; many configuration changes result in changes to the kernel ABI. So you can apply your argument to say in general that the kernel isn’t 100% stable. Note that in your answer, you specifically said “hoping that it doesn't change across kernel versions”; I was reacting to that.
– Stephen Kitt
Dec 19 at 9:32
It's still not 100% stable. E.g: github.com/collectd/collectd/issues/2951
– V13
Dec 20 at 0:28
add a comment |
this may not be the answer you are looking for, Yes for your first question, it stays but dont think it would be expensive per say (too many variables). For the second question, I do not know. You may want to try to "test" adding commands to clear memory to your procedure you are running as you monitor the load on the system.
sync; echo 1 > /proc/sys/vm/drop_caches
sync; echo 2 > /proc/sys/vm/drop_caches
sync; echo 3 > /proc/sys/vm/drop_caches
answered Dec 16 at 19:57
user741162
81
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%2f489368%2fis-reading-proc-repeatedly-expensive%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Reading from /proc as a user every second is not expensive under normal conditions. There are however a couple of files that can be expensive because they require kernel-side locking that can delay other things.
E.g. this may be such a case: https://serverfault.com/questions/943866/proc-sys-net-netfilter-nf-conntrack-count-extreme-drop-when-reading-proc-net-n
Programs like top and conntrack will try to use other means (e.g. netlink) for multiple reasons:
/procis a text-based approach that's not 100% stable. A program needs to scan a file and parse it, hoping that it doesn't change across kernel versions- As mentioned, some /proc files may be expensive to read, also depending on their size
- The
netlinkapproach can return more information than/proc
answered Dec 16 at 19:55
V13
2,799613
1
The/procinterface is part of the kernel ABI, and therefore maintained with the same stability guarantees as system calls etc.
– Stephen Kitt
Dec 17 at 6:05
@StephenKitt that doesn't make it 100% stable though because the presence of some files depends on the kernel configuration. E.g. CONFIG_PROC_PID_CPUSET, CONFIG_PROC_CHILDREN, etc. Also doesn't ensure their presence across systems of the same kernel version.
– V13
Dec 19 at 1:41
That’s not specific to/proc; many configuration changes result in changes to the kernel ABI. So you can apply your argument to say in general that the kernel isn’t 100% stable. Note that in your answer, you specifically said “hoping that it doesn't change across kernel versions”; I was reacting to that.
– Stephen Kitt
Dec 19 at 9:32
It's still not 100% stable. E.g: github.com/collectd/collectd/issues/2951
– V13
Dec 20 at 0:28
add a comment |
Reading from /proc as a user every second is not expensive under normal conditions. There are however a couple of files that can be expensive because they require kernel-side locking that can delay other things.
E.g. this may be such a case: https://serverfault.com/questions/943866/proc-sys-net-netfilter-nf-conntrack-count-extreme-drop-when-reading-proc-net-n
Programs like top and conntrack will try to use other means (e.g. netlink) for multiple reasons:
/procis a text-based approach that's not 100% stable. A program needs to scan a file and parse it, hoping that it doesn't change across kernel versions- As mentioned, some /proc files may be expensive to read, also depending on their size
- The
netlinkapproach can return more information than/proc
answered Dec 16 at 19:55
V13
2,799613
1
The/procinterface is part of the kernel ABI, and therefore maintained with the same stability guarantees as system calls etc.
– Stephen Kitt
Dec 17 at 6:05
@StephenKitt that doesn't make it 100% stable though because the presence of some files depends on the kernel configuration. E.g. CONFIG_PROC_PID_CPUSET, CONFIG_PROC_CHILDREN, etc. Also doesn't ensure their presence across systems of the same kernel version.
– V13
Dec 19 at 1:41
That’s not specific to/proc; many configuration changes result in changes to the kernel ABI. So you can apply your argument to say in general that the kernel isn’t 100% stable. Note that in your answer, you specifically said “hoping that it doesn't change across kernel versions”; I was reacting to that.
– Stephen Kitt
Dec 19 at 9:32
It's still not 100% stable. E.g: github.com/collectd/collectd/issues/2951
– V13
Dec 20 at 0:28
add a comment |
Reading from /proc as a user every second is not expensive under normal conditions. There are however a couple of files that can be expensive because they require kernel-side locking that can delay other things.
E.g. this may be such a case: https://serverfault.com/questions/943866/proc-sys-net-netfilter-nf-conntrack-count-extreme-drop-when-reading-proc-net-n
Programs like top and conntrack will try to use other means (e.g. netlink) for multiple reasons:
/procis a text-based approach that's not 100% stable. A program needs to scan a file and parse it, hoping that it doesn't change across kernel versions- As mentioned, some /proc files may be expensive to read, also depending on their size
- The
netlinkapproach can return more information than/proc
answered Dec 16 at 19:55
V13
2,799613
Reading from /proc as a user every second is not expensive under normal conditions. There are however a couple of files that can be expensive because they require kernel-side locking that can delay other things.
E.g. this may be such a case: https://serverfault.com/questions/943866/proc-sys-net-netfilter-nf-conntrack-count-extreme-drop-when-reading-proc-net-n
Programs like top and conntrack will try to use other means (e.g. netlink) for multiple reasons:
/procis a text-based approach that's not 100% stable. A program needs to scan a file and parse it, hoping that it doesn't change across kernel versions- As mentioned, some /proc files may be expensive to read, also depending on their size
- The
netlinkapproach can return more information than/proc
answered Dec 16 at 19:55
V13
2,799613
edited Dec 16 at 20:09
answered Dec 16 at 19:55
V13
2,799613
answered Dec 16 at 19:55
V13
2,799613
answered Dec 16 at 19:55
V13
2,799613
2,799613
1
The/procinterface is part of the kernel ABI, and therefore maintained with the same stability guarantees as system calls etc.
– Stephen Kitt
Dec 17 at 6:05
@StephenKitt that doesn't make it 100% stable though because the presence of some files depends on the kernel configuration. E.g. CONFIG_PROC_PID_CPUSET, CONFIG_PROC_CHILDREN, etc. Also doesn't ensure their presence across systems of the same kernel version.
– V13
Dec 19 at 1:41
That’s not specific to/proc; many configuration changes result in changes to the kernel ABI. So you can apply your argument to say in general that the kernel isn’t 100% stable. Note that in your answer, you specifically said “hoping that it doesn't change across kernel versions”; I was reacting to that.
– Stephen Kitt
Dec 19 at 9:32
It's still not 100% stable. E.g: github.com/collectd/collectd/issues/2951
– V13
Dec 20 at 0:28
add a comment |
1
The/procinterface is part of the kernel ABI, and therefore maintained with the same stability guarantees as system calls etc.
– Stephen Kitt
Dec 17 at 6:05
@StephenKitt that doesn't make it 100% stable though because the presence of some files depends on the kernel configuration. E.g. CONFIG_PROC_PID_CPUSET, CONFIG_PROC_CHILDREN, etc. Also doesn't ensure their presence across systems of the same kernel version.
– V13
Dec 19 at 1:41
That’s not specific to/proc; many configuration changes result in changes to the kernel ABI. So you can apply your argument to say in general that the kernel isn’t 100% stable. Note that in your answer, you specifically said “hoping that it doesn't change across kernel versions”; I was reacting to that.
– Stephen Kitt
Dec 19 at 9:32
It's still not 100% stable. E.g: github.com/collectd/collectd/issues/2951
– V13
Dec 20 at 0:28
1
1
The
/proc interface is part of the kernel ABI, and therefore maintained with the same stability guarantees as system calls etc.– Stephen Kitt
Dec 17 at 6:05
The
/proc interface is part of the kernel ABI, and therefore maintained with the same stability guarantees as system calls etc.– Stephen Kitt
Dec 17 at 6:05
@StephenKitt that doesn't make it 100% stable though because the presence of some files depends on the kernel configuration. E.g. CONFIG_PROC_PID_CPUSET, CONFIG_PROC_CHILDREN, etc. Also doesn't ensure their presence across systems of the same kernel version.
– V13
Dec 19 at 1:41
@StephenKitt that doesn't make it 100% stable though because the presence of some files depends on the kernel configuration. E.g. CONFIG_PROC_PID_CPUSET, CONFIG_PROC_CHILDREN, etc. Also doesn't ensure their presence across systems of the same kernel version.
– V13
Dec 19 at 1:41
That’s not specific to
/proc; many configuration changes result in changes to the kernel ABI. So you can apply your argument to say in general that the kernel isn’t 100% stable. Note that in your answer, you specifically said “hoping that it doesn't change across kernel versions”; I was reacting to that.– Stephen Kitt
Dec 19 at 9:32
That’s not specific to
/proc; many configuration changes result in changes to the kernel ABI. So you can apply your argument to say in general that the kernel isn’t 100% stable. Note that in your answer, you specifically said “hoping that it doesn't change across kernel versions”; I was reacting to that.– Stephen Kitt
Dec 19 at 9:32
It's still not 100% stable. E.g: github.com/collectd/collectd/issues/2951
– V13
Dec 20 at 0:28
It's still not 100% stable. E.g: github.com/collectd/collectd/issues/2951
– V13
Dec 20 at 0:28
add a comment |
this may not be the answer you are looking for, Yes for your first question, it stays but dont think it would be expensive per say (too many variables). For the second question, I do not know. You may want to try to "test" adding commands to clear memory to your procedure you are running as you monitor the load on the system.
sync; echo 1 > /proc/sys/vm/drop_caches
sync; echo 2 > /proc/sys/vm/drop_caches
sync; echo 3 > /proc/sys/vm/drop_caches
answered Dec 16 at 19:57
user741162
81
add a comment |
this may not be the answer you are looking for, Yes for your first question, it stays but dont think it would be expensive per say (too many variables). For the second question, I do not know. You may want to try to "test" adding commands to clear memory to your procedure you are running as you monitor the load on the system.
sync; echo 1 > /proc/sys/vm/drop_caches
sync; echo 2 > /proc/sys/vm/drop_caches
sync; echo 3 > /proc/sys/vm/drop_caches
answered Dec 16 at 19:57
user741162
81
add a comment |
this may not be the answer you are looking for, Yes for your first question, it stays but dont think it would be expensive per say (too many variables). For the second question, I do not know. You may want to try to "test" adding commands to clear memory to your procedure you are running as you monitor the load on the system.
sync; echo 1 > /proc/sys/vm/drop_caches
sync; echo 2 > /proc/sys/vm/drop_caches
sync; echo 3 > /proc/sys/vm/drop_caches
answered Dec 16 at 19:57
user741162
81
this may not be the answer you are looking for, Yes for your first question, it stays but dont think it would be expensive per say (too many variables). For the second question, I do not know. You may want to try to "test" adding commands to clear memory to your procedure you are running as you monitor the load on the system.
sync; echo 1 > /proc/sys/vm/drop_caches
sync; echo 2 > /proc/sys/vm/drop_caches
sync; echo 3 > /proc/sys/vm/drop_caches
answered Dec 16 at 19:57
user741162
81
edited Dec 16 at 20:10
answered Dec 16 at 19:57
user741162
81
answered Dec 16 at 19:57
user741162
81
answered Dec 16 at 19:57
user741162
81
81
add a comment |
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f489368%2fis-reading-proc-repeatedly-expensive%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
1
Note that
/procdoesn't "live inside memory". When you interact with files in/proc, you call kernel functions, which supply the answer etc. The cost of this depends a lot on the function that is called. In many cases the cost is low.– dirkt
Dec 17 at 9:07