From: "Jin, Yao" <yao.jin@linux.intel.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: acme@kernel.org, jolsa@kernel.org, peterz@infradead.org,
mingo@redhat.com, alexander.shishkin@linux.intel.com,
Linux-kernel@vger.kernel.org, ak@linux.intel.com,
kan.liang@intel.com, yao.jin@intel.com,
linuxppc-dev@lists.ozlabs.org, treeze.taeung@gmail.com
Subject: Re: [PATCH v4 0/5] perf report: Show branch type
Date: Thu, 13 Apr 2017 11:25:39 +0800 [thread overview]
Message-ID: <c480d004-8a02-65fb-48b5-6db43b8efa4f@linux.intel.com> (raw)
In-Reply-To: <74ee84f8-e756-65d2-9ba4-b560f6e241bd@linux.intel.com>
On 4/13/2017 10:00 AM, Jin, Yao wrote:
>
>
> On 4/12/2017 6:58 PM, Jiri Olsa wrote:
>> On Wed, Apr 12, 2017 at 06:21:01AM +0800, Jin Yao wrote:
>>
>> SNIP
>>
>>> 3. Use 2 bits in perf_branch_entry for a "cross" metrics checking
>>> for branch cross 4K or 2M area. It's an approximate computing
>>> for checking if the branch cross 4K page or 2MB page.
>>>
>>> For example:
>>>
>>> perf record -g --branch-filter any,save_type <command>
>>>
>>> perf report --stdio
>>>
>>> JCC forward: 27.7%
>>> JCC backward: 9.8%
>>> JMP: 0.0%
>>> IND_JMP: 6.5%
>>> CALL: 26.6%
>>> IND_CALL: 0.0%
>>> RET: 29.3%
>>> IRET: 0.0%
>>> CROSS_4K: 0.0%
>>> CROSS_2M: 14.3%
>> got mangled perf report --stdio output for:
>>
>>
>> [root@ibm-x3650m4-02 perf]# ./perf record -j any,save_type kill
>> kill: not enough arguments
>> [ perf record: Woken up 1 times to write data ]
>> [ perf record: Captured and wrote 0.013 MB perf.data (18 samples) ]
>>
>> [root@ibm-x3650m4-02 perf]# ./perf report --stdio -f | head -30
>> # To display the perf.data header info, please use
>> --header/--header-only options.
>> #
>> #
>> # Total Lost Samples: 0
>> #
>> # Samples: 253 of event 'cycles'
>> # Event count (approx.): 253
>> #
>> # Overhead Command Source Shared Object Source
>> Symbol Target
>> Symbol Basic Block Cycles
>> # ........ ....... ....................
>> .......................................
>> ....................................... ..................
>> #
>> 8.30% perf
>> Um [kernel.vmlinux] [k] __intel_pmu_enable_all.constprop.17
>> [k] native_write_msr -
>> 7.91% perf
>> Um [kernel.vmlinux] [k] intel_pmu_lbr_enable_all
>> [k] __intel_pmu_enable_all.constprop.17 -
>> 7.91% perf
>> Um [kernel.vmlinux] [k] native_write_msr
>> [k] intel_pmu_lbr_enable_all -
>> 6.32% kill libc-2.24.so [.]
>> _dl_addr [.]
>> _dl_addr -
>> 5.93% perf
>> Um [kernel.vmlinux] [k] perf_iterate_ctx
>> [k] perf_iterate_ctx -
>> 2.77% kill libc-2.24.so [.]
>> malloc [.]
>> malloc -
>> 1.98% kill libc-2.24.so [.]
>> _int_malloc [.]
>> _int_malloc -
>> 1.58% kill [kernel.vmlinux] [k]
>> __rb_insert_augmented [k]
>> __rb_insert_augmented -
>> 1.58% perf
>> Um [kernel.vmlinux] [k] perf_event_exec
>> [k] perf_event_exec -
>> 1.19% kill [kernel.vmlinux] [k]
>> anon_vma_interval_tree_insert [k]
>> anon_vma_interval_tree_insert -
>> 1.19% kill [kernel.vmlinux] [k]
>> free_pgd_range [k]
>> free_pgd_range -
>> 1.19% kill [kernel.vmlinux] [k]
>> n_tty_write [k]
>> n_tty_write -
>> 1.19% perf
>> Um [kernel.vmlinux] [k] native_sched_clock
>> [k] sched_clock -
>> ...
>> SNIP
>>
>>
>> jirka
>
> Sorry, I look at this issue at midnight in Shanghai. I misunderstood
> that the above output was only a mail format issue. Sorry about that.
>
> Now I recheck the output, and yes, the perf report output is mangled.
> But my patch doesn't touch the associated code.
>
> Anyway I remove my patches, pull the latest update from perf/core
> branch and run tests to check if its a regression issue. I test on HSW
> and SKL both.
>
> 1. On HSW.
>
> root@hsw:/tmp# perf record -j any kill
> ...... /* SNIP */
> For more details see kill(1).
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.014 MB perf.data (9 samples) ]
>
> root@hsw:/tmp# perf report --stdio
> # To display the perf.data header info, please use
> --header/--header-only options.
> #
> #
> # Total Lost Samples: 0
> #
> # Samples: 144 of event 'cycles'
> # Event count (approx.): 144
> #
> # Overhead Command Source Shared Object Source
> Symbol Target Symbol Basic Block
> Cycles
> # ........ ....... ....................
> ............................... ...............................
> ..................
> #
> 10.42% kill libc-2.23.so [.]
> read_alias_file [.] read_alias_file -
> 9.72% kill [kernel.vmlinux] [k]
> update_load_avg [k] update_load_avg -
> 9.03% perf
> Um [unknown] [k] 0000000000000000 [k]
> 0000000000000000 -
> 8.33% kill libc-2.23.so [.]
> _int_malloc [.] _int_malloc -
> ...... /* SNIP */
> 0.69% kill [kernel.vmlinux] [k]
> _raw_spin_lock [k] unmap_page_range -
> 0.69% perf
> Um [kernel.vmlinux] [k] __intel_pmu_enable_all [k]
> native_write_msr -
> 0.69% perf
> Um [kernel.vmlinux] [k] intel_pmu_lbr_enable_all [k]
> __intel_pmu_enable_all -
> 0.69% perf
> Um [kernel.vmlinux] [k] native_write_msr [k]
> intel_pmu_lbr_enable_all -
>
> The issue is still there.
>
> 2. On SKL
>
> root@skl:/tmp# perf record -j any kill
> ...... /* SNIP */
> For more details see kill(1).
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.012 MB perf.data (1 samples) ]
>
> root@skl:/tmp# perf report --stdio
>
> # To display the perf.data header info, please use
> --header/--header-only options.
> #
> #
> # Total Lost Samples: 0
> #
> # Samples: 32 of event 'cycles'
> # Event count (approx.): 32
> #
> # Overhead Command Source Shared Object Source
> Symbol Target Symbol Basic Block Cycles
> # ........ ....... ....................
> ............................ ............................
> ..................
> #
> 90.62% perf
> Um [unknown] [k] 0000000000000000 [k]
> 0000000000000000 -
> 3.12% perf
> Um [kernel.vmlinux] [k] __intel_pmu_enable_all [k]
> native_write_msr 11
> 3.12% perf
> Um [kernel.vmlinux] [k] intel_pmu_lbr_enable_all [k]
> __intel_pmu_enable_all 4
> 3.12% perf
> Um [kernel.vmlinux] [k] native_write_msr [k]
> intel_pmu_lbr_enable_all -
>
> The issue is there too.
>
> Now it works without my patch and it runs with latest perf/core
> branch. So it looks like a regression issue.
>
> Thanks
> Jin Yao
>
>
I have tested, the regression issue is happened after this commit:
bdd97ca perf tools: Refactor the code to strip command name with {l,r}trim()
CC to the author for double checking.
Thanks
Jin Yao
>
>
>
>
>
>
>
>
>
>
next prev parent reply other threads:[~2017-04-13 3:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-11 22:21 [PATCH v4 0/5] perf report: Show branch type Jin Yao
2017-04-11 22:21 ` [PATCH v4 1/5] perf/core: Define the common branch type classification Jin Yao
2017-04-11 22:21 ` [PATCH v4 2/5] perf/x86/intel: Record branch type Jin Yao
2017-04-11 22:21 ` [PATCH v4 3/5] perf record: Create a new option save_type in --branch-filter Jin Yao
2017-04-11 22:21 ` [PATCH v4 4/5] perf report: Show branch type statistics for stdio mode Jin Yao
2017-04-18 18:53 ` Jiri Olsa
2017-04-19 0:53 ` Jin, Yao
2017-04-19 4:11 ` Jin, Yao
2017-04-18 18:53 ` Jiri Olsa
2017-04-19 0:41 ` Jin, Yao
2017-04-11 22:21 ` [PATCH v4 5/5] perf report: Show branch type in callchain entry Jin Yao
2017-04-18 18:53 ` Jiri Olsa
2017-04-19 0:33 ` Jin, Yao
2017-04-18 18:53 ` Jiri Olsa
2017-04-19 0:32 ` Jin, Yao
2017-04-12 10:58 ` [PATCH v4 0/5] perf report: Show branch type Jiri Olsa
2017-04-12 12:25 ` Jin, Yao
2017-04-12 14:26 ` Jiri Olsa
2017-04-12 15:42 ` Jin, Yao
2017-04-12 15:46 ` Jiri Olsa
2017-04-13 2:00 ` Jin, Yao
2017-04-13 3:25 ` Jin, Yao [this message]
2017-04-13 8:26 ` Jiri Olsa
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=c480d004-8a02-65fb-48b5-6db43b8efa4f@linux.intel.com \
--to=yao.jin@linux.intel.com \
--cc=Linux-kernel@vger.kernel.org \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=kan.liang@intel.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=treeze.taeung@gmail.com \
--cc=yao.jin@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).