From: Milian Wolff <milian.wolff@kdab.com>
To: shiny.sebastian@intel.com
Cc: linux-perf-users@vger.kernel.org
Subject: Re: Perf report --percentage
Date: Wed, 08 Jun 2016 09:34:58 +0200 [thread overview]
Message-ID: <1936512.XMEGsyMYkf@agathebauer> (raw)
In-Reply-To: <6076A35470B38B408600AA0E3B4A31E767471A9E@ORSMSX114.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 4075 bytes --]
On Dienstag, 7. Juni 2016 19:21:15 CEST Sebastian, Shiny wrote:
> Hi,
>
> I work with Intel and am running perf tool within Linux VMs on Windows
> Hyper-V. With kernel 4.6 and corresponding perf version, percentages of
> call stacks at deeper levels do not seem to add up to 100% or parent value
> (26.97%): example below. I have tried the -percentage flag with both
> 'absolute' and 'relative' values and they don't seem to change the output
> at all. Is this a bug or something wrong with my perf flags ?
>
> Commands used:
> #perf record -a -g -c 10000 sleep 10
> #perf report -i cpu3.data.old -C 1 --no-children
>
> - 27.48% fio [kernel.kallsyms] [k] __softirqentry_text_start
> __softirqentry_text_start
> - irq_exit
> - 26.97% smp_call_function_single_interrupt
> - call_function_single_interrupt
> + 4.21% __blk_run_queue
> + 4.09% hv_ringbuffer_write
> + 1.83% 0x99c
> + 1.78% __blockdev_direct_IO
> + 0.96% do_blockdev_direct_IO
> + 0.95% generic_make_request
> + 0.86% blk_queue_bio
> + 0.70% iov_iter_get_pages
> + 0.64% md_make_request
> + 0.55% do_io_submit
> 0.51% entry_SYSCALL_64_fastpath
> + 0.51% hyperv_vector_handler
Can you try to look at the output of
perf report -i cpu3.data.old -C 1 --no-children -g graph,0
i.e. potentially there are more entries with a cost of 0.5% or less, which by
default falls below the threshold.
That said, I just tested it and it doesn't work for me either:
tmp$ perf record --call-graph dwarf kwrite
[ perf record: Woken up 65 times to write data ]
[ perf record: Captured and wrote 16.308 MB perf.data (2032 samples) ]
tmp$ perf report -g graph,0 --no-children
- 9.47% kwrite ld-2.23.so [.] do_lookup_x
- 2.21% do_lookup_x
- _dl_lookup_symbol_x
+ 1.42% _dl_relocate_object
+ 0.74% _dl_fixup
+ 7.06% kwrite ld-2.23.so [.] strcmp
It's also bogus when I look at it with --children:
- 10.76% 9.47% kwrite ld-2.23.so [.] do_lookup_x
+ 1.54% _start
+ 1.34% do_lookup_x
+ 0.61% _dl_runtime_resolve_avx
- 7.06% 7.06% kwrite ld-2.23.so [.] strcmp
+ 0.42% _start
+ 0.22% _dl_runtime_resolve_avx
So someone else with more insight should answer whether this output can be
explained somehow.
> Older version: Perf version 4.2 on kernel 4.2 - seems to normalize them to
> 100%. 27.69% swapper [kernel.kallsyms] [k] intel_idle
>
> ---intel_idle
>
> |--99.84%-- cpuidle_enter_state
> |
> | cpuidle_enter
> | call_cpuidle
> | cpu_startup_entry
> |
> | |--97.27%-- start_secondary
> | |
> | --2.73%-- rest_init
> |
> | start_kernel
> | x86_64_start_reservations
> | x86_64_start_kernel
>
> --0.16%-- [...]
This output can be reproduced on newer perf by passing `-g fractal` to `perf
report`. I still get the issues as shown above though with a newer perf:
- 9.47% kwrite ld-2.23.so [.] do_lookup_x
+ 23.31% do_lookup_x
- 7.06% kwrite ld-2.23.so [.] strcmp
+ 9.06% strcmp
+ 5.71% kwrite ld-2.23.so [.] check_match
I.e. ~74% and 91% of the samples don't seen to have a proper backtrace
attribution?
Cheers
--
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]
next prev parent reply other threads:[~2016-06-08 7:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-07 19:21 Perf report --percentage Sebastian, Shiny
2016-06-08 7:34 ` Milian Wolff [this message]
2016-06-08 16:21 ` Sebastian, Shiny
2016-06-11 8:31 ` Namhyung Kim
2016-06-11 11:53 ` Milian Wolff
2016-06-12 13:55 ` Namhyung Kim
2016-06-13 11:01 ` Milian Wolff
2016-06-09 15:13 ` Arnaldo Carvalho de Melo
2016-06-10 3:14 ` Namhyung Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1936512.XMEGsyMYkf@agathebauer \
--to=milian.wolff@kdab.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=shiny.sebastian@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.