| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 13 Apr 2017 11:25:39 +0800
From: "Jin, Yao" <yao.jin@...ux.intel.com>
To: Jiri Olsa <jolsa@...hat.com>
Cc: acme@...nel.org, jolsa@...nel.org, peterz@...radead.org,
mingo@...hat.com, alexander.shishkin@...ux.intel.com,
Linux-kernel@...r.kernel.org, ak@...ux.intel.com,
kan.liang@...el.com, yao.jin@...el.com,
linuxppc-dev@...ts.ozlabs.org, treeze.taeung@...il.com
Subject: Re: [PATCH v4 0/5] perf report: Show branch type
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@...-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@...-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
>
>
>
>
>
>
>
>
>
>
Powered by blists - more mailing lists