關於系統調用的perf報告

Question

我為進程A，B提供了針對perf報告（關於malloc）的以下輸出：

記錄：perf記錄-e周期：你

流程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的情況下，沒有發生系統調用，因為在進程B的性能報告中，根本沒有[k] system_call！

Answer 1

你沒有得到一些程序通過使用采樣調用的所有函數，你會得到一些被調用的函數，那些事件被采樣最多的函數，對於“周期：你”，你會得到“最熱”的用戶空間中的函數（沒有內核函數）。

考慮使用跟蹤而不是采樣，例如：'perf trace workload'。 考慮使用它的回溯，例如，查看'brk'系統調用的回溯，我們可以得到'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)

這表明在這種情況下調用了系統調用，以響應調用malloc（）的strdup（），最終通過'brk'調用向內核核心詢問更多內存。

再玩'perf trace'，你會發現像'strace'提供的統計數據，例如，一個程序叫做brk和其他系統調用的次數。

Answer 2

是的，似乎合情合理。 可能進程B從內核獲取了一些內存，然后能夠滿足自由列表中的所有分配。 即自由列表從來沒有足夠大（或太碎片）glibc的malloc實現決定將任何頁面返回到內核。

這一切都歸結為分配/解除分配模式和映射的大小。 對於大型malloc請求，glibc直接使用mmap(MAP_ANONYMOUS) ，因此可以free對其進行munmap 。