perf report出现无文件名[unknown]共享对象缓存缺失问题咨询

Samples: 3M of event 'cache-misses', Event count (approx.): 35941375181
  Children      Self  Command    Shared Object            Symbol                                                                                                                                                                            
    14.74%    14.72%  exe        exe                      [.] symbolA                                                                                                              
+   12.07%     0.00%  exe        [unknown]                [.] 0000000000000000                                                                                                                                                        
+   10.33%     0.00%  exe        [unknown]                [.] 0x0000000300000002                                                                                                                                                      
+    9.09%     0.00%  exe        [unknown]                [k] 0x3ff0000000000000                                                                                                                                                      
+    7.67%     7.67%  exe        exe                      [.] symbolB  

perf的工作流分采样和后处理两个完全独立的阶段，[unknown]标记是后处理阶段地址映射失败导致的，和采样本身无关，常见触发场景：

• 抓到无效指令地址：比如输出里的0000000000000000就是典型的空指针地址，一般是栈溢出破坏返回地址、异常控制流跳转到未映射内存区导致的，这类地址根本没有对应的文件映射，自然匹配不到共享库名。
• 地址对应无文件 backing 的可执行内存：比如JIT运行时动态生成的代码、动态链接器生成的跳转跳板、程序自行申请可执行权限内存写入的机器码，这类代码直接存在于内存中，没有对应的磁盘文件，perf默认不会采集这类动态代码的符号信息，就会标记为unknown。
• 权限不足无法读取映射信息：如果运行perf的用户权限不够，没法读取目标进程的/proc/<pid>/maps内存映射表，或者开启了kptr_restrict等内核安全限制屏蔽了内核地址映射，哪怕地址是合法的，perf也没法把地址对应到具体的共享库、内核模块。
• 采样落到特殊执行阶段：比如CPU正在做上下文切换、中断/异常返回的过渡状态，此时指令指针不在任何已注册的文件映射区间内，也会被判定为unknown。

perf的采样逻辑不会因为地址无法解析就丢弃样本，核心原因如下：

• 采样阶段只做最精简的上下文抓取：cache-miss是硬件PMU触发的中断，为了避免采样本身严重干扰系统运行，中断上下文中只会快速抓取CPU的指令指针、栈地址等核心寄存器值，根本不会做地址解析这类耗时操作，所以记录采样的时候根本不知道这个地址后续能不能匹配到文件名，只要硬件触发了事件就会留存样本。
• 后处理阶段只做分类不做过滤：perf report解析离线采集的采样数据时，只会把能匹配到映射的样本归到对应的共享库、符号名下，匹配失败的统一归到[unknown]分类，不会直接丢弃——这些样本确实是硬件触发cache-miss时抓到的真实上下文，本身就是统计结果的一部分。
• 你看到的这几个unknown条目Self占比都是0%，说明这些地址本身没有直接触发cache-miss，只是调用栈展开时落到了无法解析的位置，Children列的占比是它下游调用链上累计的cache-miss占比，所以数值看起来不低。

内容的提问来源于stack exchange，提问作者Frank Puck