0

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)?

Mas Bagol
  • 605
  • 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 '18 at 09:07

2 Answers2

4

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:

  • /proc is 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 netlink approach can return more information than /proc
V13
  • 4,749
  • 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 '18 at 06: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 '18 at 01: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 '18 at 09:32
  • It's still not 100% stable. E.g: https://github.com/collectd/collectd/issues/2951 – V13 Dec 20 '18 at 00:28
0

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

user741162
  • 1