Skip to content
Advertisement

how to get rid of the “unknown” section in the perf

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 reportn", 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?

Advertisement

Answer

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.

Advertisement