如何摆脱性能中的“未知”部分

Question

what I did is:

1. sudo rm -rf /root/.debug/
2. compile program with -g -O2 -fno-omit-frame-pointer
3. run the program and get the pid
4. sudo perf record -F 2000 -a -s -g -p $pid sleep 15
5. sudo perf report

then I get a tiny part of "unknown", like

-    2.50%     0.00%  postgres  [unknown]            [k] 0000000000000000                                                                                                                                  
   - 0                                                                                                                                                                                                     
        1.12% _int_malloc                                                                                                                                                                                  ▒
        0.79% _IO_vsnprintf

looks this is due to libc 'malloc' call. then I write a program on the same machine to test it.

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>

int main(int argc, char *argv[])
{
    while(1) {
        printf("perf record -g -p %d -- sleep 5; perf report\n", getpid());
        sleep(1);
        void *p = malloc(10);
        memset(p, 0, 10);
        free(p);
    }
    return 0;
}

then I did the same thing as above, there is no "unknown" section.

how to explain/fix this?

Answer 1

The [unknown] block in the perf report output refers to the name of the dynamic shared object ( DSO ). perf report could not resolve the DSO path and hence it prints [unknown] . Per the latest kernel source code tree (which is 5.3.9 at the time of writing), you can see this here .

It is important to know that the determination of the DSO symbols happen with the help of the sampled event address. The function thread__resolve is responsible for doing exactly that. In older kernels, the thread__resolve method had another name - perf_event__preprocess_sample_addr .

Given the snapshot of your output, it looks like the address of the event that was sampled during perf record , is 0. This means that the address could not be resolved at all. It is an address in the kernel space (looking at the symbol [k] 0000000000000000 ) and perf in your case, could not resolve it.

The comments highlight setting perf_event_paranoid to a suitable value so that you can probe both kernel and user-space events successfully. Setting perf_event_paranoid to a value that allows you to correctly probe events in the kernel space should "be a step" towards correctly resolving the address.