On Mon, 7 Mar 2016 21:20:18 +0100 Damjan Georgievski <gdamjan@gmail.com> wrote:
The free command gets its information from /proc/meminfo. Performance-wise, it doesn't really matter if a few additional lines need to be parsed.
Hello, Thank you Florian. Actually, I already knew it's the same, I just thought that he could use the free command instead of parsing it himself. You're right. Performance-wise, it's pretty much the same.
Sorry, I didn't express myself properly. I didn't mean to criticize free. What I meant to say was that the time it takes to parse /proc/meminfo or free is negligible. It doesn't need to be any more efficient. free parses /proc/meminfo. libgtop parses /proc/meminfo. Querying the information probably takes much more time than parsing it.
Your suggestion to use free may indeed be useful if the original poster wants parsing to be slightly simpler and does not mind the additional dependency. My impression was that they considered parsing to be too inefficient.
there's also `sysinfo(2)`
ah, thank you! and now that i found (or rather, thought about it) the source for /proc/meminfo [0] i can see that it uses sysinfo too. but sadly the cached size is not in sysinfo. then i tried to do what /proc/stat [1] does and after googling learned some facts: - you can't use "kernel-space" functions in "user-space" apps - so i cant use all the same functions as /proc/stat uses - you can't create new "syscall" functions in a kernel module - so i can't "export/map" those "kernel-space" functions to be used in my "user-space" app so it seems the only way to get deeper than /proc/stat would be to add new "syscalls" to the linux kernel? (for functions like for_each_possible_cpu and kcpustat_cpu) i'm just a webmonkey, so ill stick to /proc for now :D (i cant notice my daemon in cpu usage yet, so not really a "problem") Cheers Andre Schmidt [0] https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/fs... [1] https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/fs...