Rasmus Villemoes 0ce657c576 linux/getsysstats.c: use sysinfo() instead of parsing /proc/meminfo ... Profiling git's test suite, Linus noted [1] that a disproportionately large amount of time was spent reading /proc/meminfo. This is done by the glibc functions get_phys_pages and get_avphys_pages, but they only need the MemTotal and MemFree fields, respectively. That same information can be obtained with a single syscall, sysinfo, instead of six: open, fstat, mmap, read, close, munmap. While sysinfo also provides more than necessary, it does a lot less work than what the kernel needs to do to provide the entire /proc/meminfo. Both strace -T and in-app microbenchmarks shows that the sysinfo() approach is roughly an order of magnitude faster. sysinfo() is much older than what glibc currently requires, so I don't think there's any reason to keep the old parsing code. Moreover, this makes get_[av]phys_pages work even in the absence of /proc. Linus noted that something as simple as 'bash -c "echo"' would trigger the reading of /proc/meminfo, but gdb says that many more applications than just bash are affected: Starting program: /bin/bash "-c" "echo" Breakpoint 1, __get_phys_pages () at ../sysdeps/unix/sysv/linux/getsysstats.c:283 283 ../sysdeps/unix/sysv/linux/getsysstats.c: No such file or directory. (gdb) bt So it seems that any application that uses qsort on a moderately sized array will incur this cost (once), which is obviously proportionately more expensive for lots of short-lived processes (such as the git test suite). [1] http://thread.gmane.org/gmane.linux.kernel/2019285 Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk> * sysdeps/unix/sysv/linux/getsysstats.c (__get_phys_pages): Use sysinfo system call instead of parsing /proc/meminfo. * sysdeps/unix/sysv/linux/getsysstats.c (__get_avphys_pages): Likewise.		2015-09-12 21:09:59 -04:00
..
sysinfo.h	linux/getsysstats.c: use sysinfo() instead of parsing /proc/meminfo	2015-09-12 21:09:59 -04:00
timex.h	Update copyright dates with scripts/update-copyrights.	2015-01-02 16:29:47 +00:00