perf系统呼叫报告

Question

对于进程A，B的perf报告(有关malloc)，我有以下输出：

记录: perf记录-e周期:U

进程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

此外，工艺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

它们都在源代码中做了一些malloc操作。

请允许我假设在进程A的情况下，malloc确实会发生系统调用，但是在进程B的情况下，没有发生系统调用，因为在Process B perf报告中，根本没有k system_call！

Answer 1

是的，看上去很合理。进程B可能一次从内核获得一些内存，然后就能够满足它从空闲列表中的所有分配。也就是说，对于glibc的malloc实现来说，空闲列表从未变得足够大(或者太零碎)，无法决定将任何页面返回内核。

这一切都归结为分配/去分配模式，以及映射的大小。对于大型malloc请求，glibc直接使用mmap(MAP_ANONYMOUS)，因此可以在free上使用munmap。

Answer 2

您不能通过使用抽样来获得某个程序调用的所有函数，您将得到一些被调用的函数，对于“周期:U”，您将得到用户空间中“最热”的函数(没有内核函数)。

考虑使用跟踪而不是抽样，类似于：“perf跟踪工作负载”。考虑使用回溯，例如，查看'brk‘syscall 'ls’我们可以得到的回溯：

# perf trace -e brk --call-graph dwarf ls
   0.933 (0.009 ms): ls brk(brk: 0x5577c4683000) = 0x5577c4683000
                     __brk (/usr/lib64/libc-2.26.so)
                     __GI___sbrk (inlined)
                     __GI___default_morecore (inlined)
                     sysmalloc (/usr/lib64/libc-2.26.so)
                     _int_malloc (/usr/lib64/libc-2.26.so)
                     tcache_init.part.5 (/usr/lib64/libc-2.26.so)
                     __GI___libc_malloc (inlined)
                     __GI___strdup (inlined)
                     [0xffff80aa65b9ae49] (/usr/lib64/libselinux.so.1)
                     [0xffff80aa65b9af0e] (/usr/lib64/libselinux.so.1)
                     call_init.part.0 (/usr/lib64/ld-2.26.so)
                     _dl_init (/usr/lib64/ld-2.26.so)
                     _dl_start_user (/usr/lib64/ld-2.26.so)

这表明在本例中调用syscall是为了响应名为malloc()的str举()，它最终通过'brk‘调用请求内核更多的内存。

再玩一些'perf跟踪‘，您就会发现类似于'strace’提供的统计数据，例如，一个名为brk和其他syscalls的程序有多少次。