Don`t get the kernel stack rightly by simpleperf

  1. Get the from the Android device(kenel4.9) by the follow command:

    simpleperf record -p 291 -o /data/local/tmp/ --duration 5 -g -f 22750
  2. Parse the to perf.html by -i -o perf.html
  3. Check the flow of the mmc_blk_end_queued_req function in the perf.html, I can't get the right flow about the

mmc_blk_end_queued_req , the stack should be mmc_blk_end_queued -> req_bio_endio -> bio_end, but mmc_blk_end_queued -> bio_end from the flame graph.

Take a look here

1 answer

  • answered 2021-07-24 09:42 helllo_yjcn

    I think i get it. It should be simpleper merge the stack because the stacks have the same ip and sp.

    Why we can't always get complete DWARF-based call graphs?

    DWARF-based call graphs are generated by unwinding thread stacks. When a sample is generated, up to 64KB stack data is dumped by the kernel. By unwinding the stack based on dwarf information, we get a callchain. But the thread stack can be much longer than 64KB. In that case, we can't unwind to the thread start point.

    To alleviate the problem, simpleperf joins callchains after recording them. If two callchains of a thread have an entry containing the same ip and sp address, then simpleperf tries to join them to make the callchains longer. In that case, the longer we run, the more samples we get. This makes it more likely to get complete callchains, but it's still not guaranteed to get complete call graphs.

How many English words
do you know?
Test your English vocabulary size, and measure
how many words do you know
Online Test
Powered by Examplum