Re: Wrong Perf Backtraces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Could you give me some hints about where the actual problem takes place? Is the problem with "Perf" or the hardware part (i.e., "Hardware Performance Counters")? Can I revise the problem by simply modifying the code? How much work is needed?

Your suggestions will be appreciated, because your experience and knowledge in this area is much more.


On 2020-03-23 14:33, ahmadkhorrami wrote:

It seems that my previous e-mail is not sent, properly. So, here is a link to the stackoverflow question:

The perf is for Ubuntu 18.04 with the following "uname -a" output:
Linux Ahmad-Laptop 5.0.0-37-generic #40~18.04.1-Ubuntu SMP Thu Nov 14 12:06:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux I also used a compiled Linux-5.4.7 kernel and its corresponding Perf tool.


On 2020-03-23 13:19, Jiri Olsa wrote:

On Mon, Mar 23, 2020 at 07:48:26AM +0430, ahmadkhorrami wrote:

Here is a link to the detailed question at Stackoverflow:
what perf version are you running?


I can copy it here, if needed.


On 2020-03-23 05:04, Steven Rostedt wrote:

On Mon, 23 Mar 2020 00:54:01 +0430
ahmadkhorrami <ahmadkhorrami@xxxxxxxx> wrote:

I used "Perf" to extract call graphs in an evince benchmark. The command
used is as follows:
sudo perf record -d --call-graph dwarf -c 10000 e
mem_load_uops_retired.l3_miss:uppp /opt/evince-3.28.4/bin/evince

I extracted the backtraces using "perf script" and found out that there
are many corrupted backtrace instances. Some contained repeated function
calls, for example two consecutive gmallocn()s exactly at the same
offsets. There are also some backtraces where the callers and callees do
not match.
Could you show some examples of the backtraces you mention?

Note that that mappings are correct. In other words, each single line of
the reported backtraces is correct (i.e., addresses match with
functions). But is seems that there are some function calls in the
middle, which are missed by "Perf". Strangely, in all runs (and also
with different sampling frequencies) the problem occurs exactly at the
same place.

I am really confused and looking forward to any help. I can also send
backtraces if needed.
-- Steve

[Index of Archives]     [Linux USB Development]     [Linux USB Development]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux