On Mon, Aug 22, 2016 at 09:40:52AM +0200, Michal Hocko wrote: > On Mon 22-08-16 09:07:45, Minchan Kim wrote: > [...] > > #!/bin/sh > > ./smap_test & > > pid=$! > > > > for i in $(seq 25) > > do > > awk '/^Rss/{rss+=$2} /^Pss/{pss+=$2} END {}' \ > > /proc/$pid/smaps > > done > > kill $pid > > > > root@bbox:/home/barrios/test/smap# time ./s.sh > > pid:21973 > > > > real 0m17.812s > > user 0m12.612s > > sys 0m5.187s > > retested on the bare metal (x86_64 - 2CPUs) > Command being timed: "sh s.sh" > User time (seconds): 0.00 > System time (seconds): 18.08 > Percent of CPU this job got: 98% > Elapsed (wall clock) time (h:mm:ss or m:ss): 0:18.29 > > multiple runs are quite consistent in those numbers. I am running with > $ awk --version > GNU Awk 4.1.3, API: 1.1 (GNU MPFR 3.1.4, GNU MP 6.1.0) > > > > like a problem we are not able to address. And I would even argue that > > > we want to address it in a generic way as much as possible. > > > > Sure. What solution do you think as generic way? > > either optimize seq_printf or replace it with something faster. If it's real culprit, I agree. However, I tested your test program on my 2 x86 machines and my friend's machine. Ubuntu, Fedora, Arch They have awk 4.0.1 and 4.1.3. Result are same. Userspace speand more times I mentioned. [root@blaptop smap_test]# time awk '/^Rss/{rss+=$2} /^Pss/{pss+=$2} END {printf "rss:%d pss:%d\n", rss, pss}' /proc/3552/smaps rss:263484 pss:262188 real 0m0.770s user 0m0.574s sys 0m0.197s I will attach my test progrma source. I hope you guys test and repost the result because it's the key for direction of patchset. Thanks.
#include <sys/mman.h> int main() { unsigned long nr_vma = 0; while (1) { if (mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_SHARED|MAP_POPULATE, -1, 0) == MAP_FAILED) break; nr_vma++; }; printf("pid:%d nr_vma:%lu\n", getpid(), nr_vma); pause(); return 0; }