proc: much faster /proc/vmstat
Subsystems (2)
PATCH 1/1 proc: much faster /proc/vmstat
Every current KDE system has process named ksysguardd polling files below once in several seconds:
$ strace -e trace=open -p $(pidof ksysguardd)
Process 1812 attached
open("/etc/mtab", O_RDONLY|O_CLOEXEC) = 8
open("/etc/mtab", O_RDONLY|O_CLOEXEC) = 8
open("/proc/net/dev", O_RDONLY) = 8
open("/proc/net/wireless", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/proc/stat", O_RDONLY) = 8
open("/proc/vmstat", O_RDONLY) = 8Hell knows what it is doing but speed up reading /proc/vmstat by 33%!
Benchmark is open+read+close 1.000.000 times.
BEFORE
$ perf stat -r 10 taskset -c 3 ./proc-vmstat
Performance counter stats for 'taskset -c 3 ./proc-vmstat' (10 runs):
13146.768464 task-clock (msec) # 0.960 CPUs utilized ( +- 0.60% )
15 context-switches # 0.001 K/sec ( +- 1.41% )
1 cpu-migrations # 0.000 K/sec ( +- 11.11% )
104 page-faults # 0.008 K/sec ( +- 0.57% )
45,489,799,349 cycles # 3.460 GHz ( +- 0.03% )
9,970,175,743 stalled-cycles-frontend # 21.92% frontend cycles idle ( +- 0.10% )
2,800,298,015 stalled-cycles-backend # 6.16% backend cycles idle ( +- 0.32% )
79,241,190,850 instructions # 1.74 insn per cycle
# 0.13 stalled cycles per insn ( +- 0.00% )
17,616,096,146 branches # 1339.956 M/sec ( +- 0.00% )
176,106,232 branch-misses # 1.00% of all branches ( +- 0.18% ) 13.691078109 seconds time elapsed ( +- 0.03% )
^^^^^^^^^^^^
AFTER
$ perf stat -r 10 taskset -c 3 ./proc-vmstat
Performance counter stats for 'taskset -c 3 ./proc-vmstat' (10 runs):
8688.353749 task-clock (msec) # 0.950 CPUs utilized ( +- 1.25% )
10 context-switches # 0.001 K/sec ( +- 2.13% )
1 cpu-migrations # 0.000 K/sec
104 page-faults # 0.012 K/sec ( +- 0.56% )
30,384,010,730 cycles # 3.497 GHz ( +- 0.07% )
12,296,259,407 stalled-cycles-frontend # 40.47% frontend cycles idle ( +- 0.13% )
3,370,668,651 stalled-cycles-backend # 11.09% backend cycles idle ( +- 0.69% )
28,969,052,879 instructions # 0.95 insn per cycle
# 0.42 stalled cycles per insn ( +- 0.01% )
6,308,245,891 branches # 726.058 M/sec ( +- 0.00% )
214,685,502 branch-misses # 3.40% of all branches ( +- 0.26% ) 9.146081052 seconds time elapsed ( +- 0.07% )
^^^^^^^^^^^
---
mm/vmstat.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
mm/vmstat.c +4 -1
@@ -1592,7 +1592,10 @@ static int vmstat_show(struct seq_file *m, void *arg) {unsigned long *l = arg;unsigned long off = l - (unsigned long *)m->private; -seq_printf (m,"%s %lu\n" , vmstat_text[off], *l); + +seq_puts (m, vmstat_text[off]); +seq_put_decimal_ull (m,' ' , *l); +seq_putc (m,'\n' );return 0 ; }
On Sat, Aug 06, 2016 at 03:54:56PM +0300, Alexey Dobriyan wrote:
[sprintf sucks, let's convert numbers manually]
mm/vmstat.c static int vmstat_show(struct seq_file *m, void *arg) · line 1600
Quoted 13 lines
mm/vmstat.c +4
-1@@ -1592,7 +1592,10 @@ static int vmstat_show(struct seq_file *m, void *arg) {unsigned long *l = arg;unsigned long off = l - (unsigned long *)m->private; -seq_printf (m,"%s %lu\n" , vmstat_text[off], *l); + +seq_puts (m, vmstat_text[off]); +seq_put_decimal_ull (m,' ' , *l); +seq_putc (m,'\n' );return 0 ; }
If that manages to be a hotspot, we really should
* educate the wankers responsible for the userland code in question,
until they repent and cease committing such abominations.
* look into fixing vsnprintf().
Seriously, what the hell is vsnprintf() doing that takes so much time? It's not as if it was a complex format anyway. WTF is going on there? Where is it spending that much time?
Quoted 13 lines · Al Viro
On Sat, Aug 06, 2016 at 03:54:56PM +0300, Alexey Dobriyan wrote:
[sprintf sucks, let's convert numbers manually]
Quoted 9 lines
mm/vmstat.c +2
-1@@ -1592,7 +1592,10 @@ static int vmstat_show(struct seq_file *m, void *arg) {unsigned long *l = arg;unsigned long off = l - (unsigned long *)m->private; -seq_printf (m,"%s %lu\n" , vmstat_text[off], *l); + +seq_puts (m, vmstat_text[off]);
Quoted 8 lines
mm/vmstat.c static int vmstat_show(struct seq_file *m, void *arg) · line 1600
Quoted 4 lines
mm/vmstat.c +2
-0+seq_put_decimal_ull (m,' ' , *l); +seq_putc (m,'\n' );return 0 ; }If that manages to be a hotspot, we really should
* educate the wankers responsible for the userland code in question,
until they repent and cease committing such abominations.
I'll get right on that.
Quoted 5 lines
* look into fixing
vsnprintf().Seriously, what the hell is
vsnprintf()doing that takes so much time? It's not as if it was a complex format anyway. WTF is going on there? Where is it spending that much time?
1. format_decode() is busy looking for format specifier: 2 branches per character (not in this case, but in others)
2. approximately million branches while parsing format mini language and everywhere
3. just look at what string() does
/proc/vmstat is good case because most of its content are strings
But the patch will still be faster.