perf report about system call

Question

I have the following output for perf report (about malloc) for Process A,B :

recorded by : perf record -e cycles:u

Process A:

0.00%       1833448  Test-Recv  libc-2.17.so           [.] malloc              
0.00%       1833385  Test-Recv  [kernel.kallsyms]      [k] system_call         
0.00%        916588  Test-Recv  libc-2.17.so           [.] _int_malloc

and also the following for Process B:

24.90%   10855848444  test.exe  libc-2.17.so   [.] _int_malloc
15.78%    6881565672  test.exe  libc-2.17.so   [.] _int_free
 7.48%    3261672221  test.exe  libc-2.17.so   [.] malloc
 4.66%    2030332370  test.exe  libc-2.17.so   [.] systrim.isra.2
 2.43%    1061251259  test.exe  libc-2.17.so   [.] free
 2.12%     925588492  test.exe  test.exe       [.] main

Both of them do some malloc in source code

May I assume that in Process A case , the malloc do occur system call , But in Process B case , there is no system call happened , since in Process B perf report , there is no [k] system_call at all !!!

Answer 1

Yeah, seems reasonable. Probably process B got some memory from the kernel once, then was able to satisfy all its allocations from the free-list. i.e. the free list never got big enough (or was too fragmented) for glibc's malloc implementation to decide to give any of the pages back to the kernel.

It all comes down to allocation / deallocation patterns, and sizes of mappings. For large malloc requests, glibc uses mmap(MAP_ANONYMOUS) directly, so it can munmap it on free.